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ABSTRACT 



The 1996 Legislature directed the Minnesota Higher Education 
Services Office (HESO) , in cooperation with the Library Planning Task Force 
to, "create a plan and process to develop a statewide on-line information 
system for libraries"; this memo with attached information was submitted in 
fulfillment of that request. The name chosen for the new statewide system is 
the Minnesota Library Information System or MnLINK. MnLINK will link public, 
academic, school, and government libraries all over Minnesota so that they 
will appear to the user as a single resource; it will be a powerful statewide 
multitype library and information system and will plav a manor part in 
improving the quality of education, research, and economic development: in 
Minnesota; and it will be a gateway to the rapidly expanding world of 
information sorted in electronic formats. State-of-the-art software and 
hardware will be used to provide people with a comprehensive guide to the 
effective use of library and information resources. Also included are: the 
process and key accomplishments to date; budget information; governance 
model; and implementation timeline. Attachments include the Library Planning 
Task Force, working group and subcommittee members; a draft Request for 
Proposal I: Components Relating to an Integrated Library Management System; a 
diagram of MnLINK functions and responsibilities; and a checklist of 
requirements for participants. (AEF) 
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Plan for a Statewide On-Line Information System for Libraries (MnLINK) 





Legislative Request. The 1996 Legislature directed the Higher Education Services Office (HESO), in 
cooperation with the Library Planning Task Force to, “create a plan and process to develop a statewide 
on-line information system for libraries,” and asked that we provide the chairs of the higher education 
committees in the House and Senate with, “ a plan... including a proposed implementation timeline, 
technical standards, draft request for proposal, and a budget.” Laws of Minnesota for 1996, Chapter 
395, Section 2(b). This memo and the attached information are submitted in fulfillment of that request. 

Brief Description of the Proposed On-Line Library System. The name chosen by the Library 
Planning Task Force for the new statewide system is the Minnesota Library Information System or 
“MnLINK”. 



• MnLINK will link public libraries, academic libraries, school libraries, and government 
libraries all over Minnesota so that they will appear to the user as a single resource. 

• MnLINK will be a powerful statewide multitype library and information system and will 
play a major part in improving the quality of education, research, and economic 
development in Minnesota. 

• MnLINK will be a gateway to the rapidly expanding world of information stored in 
electronic formats. State-of-the-art software and hardware technology will be used to 
provide people with a comprehensive guide to the effective use of library and 
information resources. 

After considerable discussion within the Library Planning Task Force as well as feedback from 
interested citizens, policy makers, librarians and educators, we determined the system we created could 
best meet the multiple and varied needs of differing libraries and library patrons by providing two 
technical components to MnLINK. 
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• System X- An Integrated Library System, replacing the University of Minnesota’s outdated 
online system (LUMINA) and the Minnesota State Colleges and Universities PALS online 
system, and including state government libraries, private college libraries, and public and 
K-12 school library media centers choosing to participate. 

• The Gateway - A common services gateway enabling libraries with existing local and 
regional automated systems to link with System X and with each other. This component 
consists of web client/servers and interface software. 

The Process and Key Accomplishments to Date. The Higher Education Services Office and the 
Library Planning Task Force began developing a work plan for the project as soon as the 1996 
legislation was enacted. Intensive work began with the release of planning funds on July 1, 1996. In 
the past seven months we have accomplished a great deal. The Higher Education Services Office and 
die 22 members of the Library Planning Task Force were assisted by more than two dozen other 
individuals contributing countless hours serving on committees to develop recommendations on 
governance and operations, public information and budget as well as to draft the technical requirements 
for the two major components of the request for proposal. ( Attachment A includes the membership of 
all the committees.) 

• Information Gathering and Dissemination. The Library Planning Task Force sought and 
received input and suggestions from numerous groups, organizations, and individuals who 
were interested in MnLINK. We heard testimony at Library Planning Task Force meetings, 
as well as attended meetings throughout the state. Drafts of materials were (and continue to* 
be posted on HESO’s web site). Various organizations listservs and newsletters also serve 
as vehicles to distribute information about this project. Members of the Library Planning 
Task Force will continue to present information about the project at meetings and 
conferences around the state. 

• Development of a Draft Request for Proposal (RFP). While the integrated library 
management system, “System X” and the gateway must work seamlessly to meet the needs 
of libraries and their users, it is possible that two (or more) different vendors will ultimately 
supply die component pieces of MnLINK. For this reason, the technical and functional 
capabilities of the two components were developed separately. Each component was 
developed by a subcommittee of individuals with the necessary knowledge and expertise. 

The two major sections are included in Attachment B, and will eventually be merged into a 
single Request for Proposal. 

All sections of the Request for Proposal will continue to be reviewed and revised. This is necessary to 
ensure that state information policies and practices as well as updated and newly released national and 
international information and library standards are accurately reflected in the Request for Proposal when 
it is finally released. We have enjoyed effective working relationships with both the Information Policy 
Office and the Office of Technology and expect their continued involvement in fine tuning the substance 
and language of the Request for Proposal. We also expect RMG Consultants, Inc. (a national library 
consulting firm retained by the Services Office to provide technical expertise) to provide additional 
assistance in this process, particularly in completing a risk assessment. Finally, we will be working 
with staff from the Contract area of the Department of Administration to guarantee that the final Request 
for Proposal is fully compliant with all relevant state of Minnesota contract requirements. 
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In November, a Request for Information (RFI) was sent to all vendors of library system software known 
to have installations in Minnesota. Additional major library system software vendors were added to the 
mailing. Vendors were presented with six “what-if” scenarios and asked to respond to any or all which 
they could satisfy. Based on the 15 responses received, we determined that our proposed budget for 
implementing MnLINK was adequate. We also identified several areas in which we need to provide 
additional information and/or modeling to provide the technical specifications needed in the final 
Request for Proposals. 

MNLink: Budget Information. 

There are several factors that make it difficult to develop a detailed project budget now. First and of 
greatest impact, while the functionality of MnLINK has been specified, its architecture will be 
determined by the selected vendor(s). For example, an architecture which is centralized will incur 
different categories of costs than one which is distributed. Similarly, the interaction between the 
integrated library management system and the gateway is complex; larger numbers of participants in one 
with correspondingly smaller numbers in the other will affect implementation costs as well as operating 
expenditures. Decisions yet-to-be-made about which libraries will participate in which components of 
MnLINK and when they will be ready to join are also factors. Over the long term, numbers of end 
users, their location and the nature of the services they use will also affect the operating costs for 
MnLINK. 

• Legislative Request. HESO’s budget request includes a biennial request for $12.76 million 
for MnLINK. The Governor has recommended $12.0 million, and IPO has approved the 
request for the entire amount. 



Based on the information we received in response to the November 1996 Request for 
Information, we believe that the following figures are reasonable approximations of 
what we will need to invest in the first two years of MnLINK implementation. While 
the ranges varied considerably, the consultant who provided the analysis of the Request 
for Information’s believes that the $12.76 million is a reasonable request. 



• System X (hardware and software and vendor $ 3.9 - 10 million 

supplied technical assistance) 

• Gateway (hardware and software servers and $2.1 - 6.6 million 

vendor supplied technical assistance) 



• Record Conversion (@10-1 5 C/record)* 



$ 2 million 



• Project Management (project staff, contracts for $ 600,000 - 750,000 

technical assistance, travel, committee expenses) 



*This figure is highly dependent on the number of overall participating libraries. 
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Because of the uncertainty about how many sites can be brought into MnLINK during the first two 
years, we request authority to carry over funds into the subsequent biennium, if necessary, to 
complete this phase of the project. As noted in the discussion of the timeline, at this time we 
anticipate that additional funds will be required to support implementation of MnLINK at additional 
sites during the 2000-2001 and 2002-2003 biennia. 

• Local Costs. The 12.76 million requested represents only a portion of the total cost of 
MnLINK. The hardware and software provided for System X and the gateway comes to the 
door of the institution and for example, does not include any computer terminals or wiring 
within the campus, school, or library. 

Operational costs for System X will be charged to participating libraries; these charges 
will be set to create a fund for equipment replacement and software upgrades. We are 
exploring what portion of operating costs for the gateway can be charged back to 
participating libraries and whether some modest state contribution for maintenance of 
the gateway system would be necessary. 

Governance Model. The Library Planning Task Force has approved the recommendation of the 
Governance Subcommittee that provides the skeleton for the governing and operations structure of 
MnLINK. Attachment C contains the model as approved by the Library Planning Task Force. Those 
recommendations include: 

• The Library Planning Task Force serve as the governing board of MnLINK until June 
30,1999. The duties of the governing board would be to: 

Establish policies and set standards for MnLINK. 

Plan for the continued development of MnLINK. 

Oversee fiscal operations, including: 

Seek and receive funding from governmental, private, and participant sources. 

Approve the MnLINK budget and fee structures for participants. 

- Contract for administrative and operational services. 

• During the next two years, a permanent governing board be created that will reflect the 
organizational structure and membership of MnLINK. One suggestion has been to explore 
the creation of a semi-governmental unit similar to the Minnesota Historical Society, or a 
public non-profit that could seek and receive private as well as public funds. 

• An Operations Council of no more than 15 members be created to: 

Oversee and operate MnLINK within the policies, standards, and budget set by the 

governing board. 

Make recommendations to the governing board on: 

Policies and Development 

- Standards 

- Budget and Fees 

- Vendors 

- Related Items 




6 



Page 5 

February 10, 1997 



• The Higher Education Services Office be the fiscal agent for the project and provide the 
project management during the implementation phase. 

• Ongoing staff for the operation of MnLINK be provided through a contract with an entity 
with the necessary skills and expertise. MnSCU PALS has expressed an interest in 
providing operational and training services on a contractual basis. 

So that potential participating libraries will know what will be expected of them if they join MnLINK, 
the Library Planning Task Force has created a Checklist for Participation. Attachment D includes the 
checklist. 

Implementation Timeline. A tentative MnLINK project timeline which will be taken to the Library 
Planning Task Force for discussion in late February. This should be viewed with some caution, since 
project vendors have not yet been selected. While there is a strong desire to get the MnLINK system 
up and running” as soon as possible, this is accompanied by an awareness of the enormity of the task. 
While other states have initiated projects which will achieve some of the same functionality as MnLINK, 
no other state has attempted to involve the whole of the library community nor to meet so extensively 
the information of all its residents. 

During the first six months of Year 1 (Fiscal Year 1998) of the project, we expect to fill project 
management roles, finalize the Request for Proposal, release it, and review responses. During the same 
period, participating libraries will begin to prepare their staffs and databases for conversation to the new 
integrated system and/or gateway. 

During the next six months, negotiations with the vendor(s) will take place and the contracts) will be 
executed. Libraries not participating in the integrated system will acquire and install any needed new 
hardware and software, while System X libraries will undertake parallel activities in preparation for the 
implementation of the integrated library management system. 



Initial installations of a small number of sites, representing a mix of System X and gateway participants, 
in the first quarter of Year 2 will be accompanied by extensive acceptance testing to assure that as part 
of this testing, we will be looking at telecommunications traffic and patterns to make sure that the load 
on the Learning Network of Minnesota will be manageable now and in the future. In the second and 
remaining quarters of Year 2, additional sites will be brought online. We anticipate that local 
conditions (systems and hardware), the availability of telecommunications infrastructure, and other 
factors will combine to spread the complete implementation of MnLINK over a five or six year period. 

In addition to the selection and installation of the system, timelines for the governance system and plan 
for providing the ongoing operational support staff are being more fully discussed by the Library 
Planning Task Force in the coming months. It is expected the Library Planning Task Force will 
approve a set of principles for the governance and operations of MNLINK by March. Once these 
guiding principles are in place and libraries begin to indicate their interest and timeline for joining 
either System X or the Gateway, the governance structure will be more fully developed. 
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Next Steps. The Higher Education Services Office and the Library Planning Task Force will continue 
to flesh out the details of this plan in the coming weeks and months. We believe we have created a 
process and a plan that will enable MnLINK to: 

• Bring the world’s knowledge and information to every Minnesotan. 

• Help Minnesota be competitive in a global economy. 

• Provide for cost-effective use of existing resources. 

• Build upon the history of library cooperation and adoption of new technologies. 

We look forward to sharing our progress with you and with other members of the legislature. Please let 
us know if there are questions or additional information that we can provide. 

LKM:dl 
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ATTACHMENT A 



MHESO - 1/30/97 



Library Planning Task Force 



r -ad Barton 
;utive Director 
MnSCU/PALS 
MSU66 
PO Box 8400 
Mankato, MN 56002-8400 
507/389-5059 
507/389-5488 fax 
dave@ms.pals.msus.edu 

Ken Behringer 
Director 

Great River Regional Library 
405 St. Germain 
St. Cloud, MN 56301 
320/251-7282 
320/251-0582 fax 
ken@grrl.lib.mn.us 

John Berling 

Dean of Learning Resource Services/ 
Director of Center for Info. Media 
St. Cloud State University 
118 Centennial Hall 
720 4th Avenue South 
St. Cloud, MN 56301-4498 
320/255-2022 ext. 4776 
320/255-4778 fax 
jberling@tigger . stcloud . msus . edu 

Dennis Cabral 

€ iociate to Senior Vice President 
ar Academic Affairs 
iversity of Minnesota 
232 Morrill Hall 
100 Church Street SE 
Minneapolis, MN 55455 
612/625-8861 
612/624-3814 fax 
cabral@mailbox.mail.umn.edu 

Gayle Ann Collins 
Northfield Public Schools 
1400 South Division 
Northfield, MN 55057 
507/663-0613 
507/663-0611 fax 
0659gac@informns .kl 2. mn.us 

Bill DeJohn 

Director 

MINITEX 

University of Minnesota 
S-33 Wilson Library 
309 19th Avenue South 
Minneapolis, MN 55455-0414 
612/624-2839 
612/624-4508 fax 
w-dejo@maroon.tc .umn.edu 

Lisa DeRemee 

Budget Division/Human Development 
Department of Finance 
' .1 Centennial Office Building 

1 ^8 Cedar Street 
St. Paul, MN 55155 
612/297-1343 
612/296-8685 fax 
" O ‘ remee@state.mn.us 




Tim Eklund, Superintendent 
Independent School District #139 
PO Box 566 
51001 Fairfield Avenue 
Rush City, MN 55069-0566 
320/358-4855, 612/224-0556 
320/358-3550 fax 
isdl39.tje@norsol.com 

Jeanne Gronquist 
1210 Wilson Avenue 
Cloquet, MN 55720 
218/879-6531 fax/Cloquet Library 

Elaine S. Hansen 
Commissioner 

Department of Administration 
50 Sherburne Avenue 
St. Paul, MN 55155 
612/296-1424 
612/297-7909 fax 
elaine.hansen@state.mn.us 

Thomas L. Houts 
3145 Dean Court #1001 
Minneapolis, MN 55416 
612/926-4468 

612/926-4468 fax (call before faxing) 

105 1 63. 1064@compuserve.com 

Michael Kathman 

Director of Libraries and Media 

College of St. Benedict/ 

St. John's University 
Collegeville, MN 56321 
320/363-2121 
320/363-2126 fax 
mkathman@csbsju.edu 

Barbara Lerschen 

Micro Systems Support & Development 
2771 South Shore Drive 
Prior Lake, MN 55372 
612/447-6498 
612/447-6498 fax 
lersc001@maroon.tc.umn.edu 

Leslie Mercer 
Director, Date & Programs 
Minnesota Higher EducationServices Office 
400 Capitol Square Building 
550 Cedar Street 
St. Paul, MN 55101 
612/296-6869 
612/297-8880 fax 
mercer@heso . state . mn.us 

David Pratt 
Piper, Jafffay Inc. 

PO Box 1139 
Minneapolis, MN 55440 
612/342-5858 
612/342-6194 fax 

Gary B. Rappaport 
3940 Walden Snores Road 
Deephaven, MN 55391 
612/931-2575 
612/931-2420 fax 
garyr@vent.com 

lG 



Robert Rohlf 
4831 Penn Avenue South 
Minneapolis, MN 55409 
612/922-4527 
612/920-9092 fax 
plcbob@bitstream.net 

Marianne Roos 
Director 

Ramsey County Library 
4570 North Victoria Street 
Shoreview, MN 55126 
612/486-2201 
612/486-2220 fax 
mroos@ramsey.lib.mn. us 

Jeff Scherer 

Meyer, Scherer, and Rockcastle, Ltd. 

119 North 2nd Street 
Minneapolis, MN 55401-1420 
612/375-0336 
612/342-2216 fax 
scher001@maroon.tc.umn.edu 

David Schroeder 
President 

Dakota County Technical College 
1300 East 145th Street 
Rosemount, MN 55068 
612/423-8200 
612/423-7028 fax 
dschr@dak.tec. mn.us 

Thomas Shaughnessy 
University Librarian 
University of Minnesota 
499 Meredith Wilson Library 
309 19th Avenue South 
Minneapolis, MN 55455 
612/624-1807 
612/626-9353 fax 
t-shau@tc.imm.edu 

Joyce Swonger 
Director 

Office of Library Development & Services 
Dept, of Children, Families & Learning 
440 Capitol Square Building 
550 Cedaur Street 
St. Paul, MN 55101 
612/296-2821 
612/296-5418 fax 
joyce.swonger@stete.mn. us 

Alternates 

Administration Alternate: 

Julie Smith 

Assistant Commissioner 
Department of Administration 
200 Administration Building 
50 Sherburne Avenue 
St. Paul, MN 55155 
612/296-8034 
612/297-7909 fax 
julie .smith@state . mn.us 




♦Margie Axtmann 
University of Minnesota Law 
Library 

120 Law Building 
229 19th Avenue South 
Minneapolis, MN SS4SS 
Phone: (612)625-4301 
FAX: (612) 625-3478 

m-axtm@tc.unm.edu 

David Barton 
MnSCU/PALS Office 
Mankato State University 
Memorial Library - MSU 66 
PO Box 8400 

Mankato, MN 56002-8400 
Phone: (507)389-5059 
FAX: (507) 389-5488 

dave@ms.pals.msus.edu 

John G. Berling 
Learning Resources Center 
St Cloud State University 
118 Centennial Hall 
720 4th Avenue South 
St Cloud, MN 56301 
Phone: (320)255-2022 
FAX: (320) 255-4778 

jberling@tigger. stcloud.msus. edu 

*Patty Biesterfeld 
Assistant Director 
Traverse des Sioux Library System 
1 10 South Broad, Box 608 
Mankato, MN 56002-0608 
Phone: (507)625-6169 
Fax: (507) 625-4049 

palspba@vaxl .mankato.msus.edu 

♦Bill DeJohn, Director 
MINITEX 

University of Minnesota Libraries 
S33 Wilson Library 
309 19th Avenue South 
Minneapolis, MN 55455 
Phone: (612)624-2839 
FAX: (612) 624-4508 

w-dejo@tc.umn.edu 

Marsha Fralick 

Minneapolis Public Library and 
Information Center 
300 Nicollet Mall 
Minneapolis, MN 55401-1925 
Phone: (612)372-6650 
FAX: (612) 372-6623 

frali001@msusl .msus.edu 



RFP Subcommittee 



Fran Galt 

Support Services Manager 
City of St Paul Public Library 
90 West 4th Street 
St. Paul, MN 55102 
Phone: (612)292-6331 
FAX: (612) 292-6660 

frang@stpaul.lib.mn.us 

Sharon Gunkel 
Kitchigami Regional Library 
PO Box 84 

Pine River, MN 56474 
Phone: (218)587-2171 
FAX: (218) 587-4855 

gunkels@northemlights . lib.mn.us 

John Houlahan 
Pioneerland Library System 
PO Box 327 
410 SW 5th Street 
Willmar, MN 56201 
Phone: (320)235-6106 
FAX: (320) 235-6106 

willmarpublib® willmar. com 

♦Michael D. Kathman 
Alcuin Library 
St John’s University 
Collegeville, MN 56321 
Phone: (320)363-2121 
FAX: (320) 363-2126 

mkathTTiaii@ cshsjii.edii 

Patricia Kovel-Jarboe 
4816 West Lake Harriet Parkway 
Minneapolis, MN 55410 
Phone: (612)920-6900 
FAX: (612) 925-1782 

patkj@maiIbox.mail.umn.edu 

♦Charlene Mason 
University of Minnesota Libraries 
499 Wilson Library 
309 19th Avenue South 
Minneapolis, MN 55455 
Phone: (612)624-4520 
FAX: (612) 626-9353 

c-maso@tc.umn.edu 

BEileen McCormack 
Department Of A dminis tration 
Information Policy Office 
320 Centennial Office Building 
658 Cedar Street 
St Paul, MN 55155 
Phone: (612)296-1415 
FAX: (612) 296-5800 

eUeen.mcconnack@state.mn. us 



Kate Olsen 

Dakota County Library 
1340 Wescott Road 
Eagan, MN 55123 
Phone: (612)688-1570 
FAX: (612) 688-1530 

kato@dakota. lib.mn.us 

♦Chris Olson 

Executive Director 

Cooperating Libraries in Consortium 

(CLIQ 

1619 Dayton Avenue 
St Paul, MN 55104 
Phone: (612)644-3878 
FAX: (612) 644-6258 

olsonc@macalester. edu 

Jane Prestebak 
714 1st Street SW 
Rochester, MN 55902 
Phone: (507)477-3598 
Phone: (507) 477-3235 (school) 
Home: (507)289-8580 
FAX: (507) 477-3230 (sch. yr.) 

FAX: (507) 288-8697 (summer) 

0203hsh@informns.kl2.mn.us 

«Ed Ruotsinoja 

University of Minnesota Libraries 
499 Wilson Library 
309 19th Avenue South 
Minneapolis, MN 55455 
Phone: (612)626-7573 
FAX: (612) 626-9353 

ruots001@staff.tc.umn.edu 



RFP Subcom mittee Project Staff 

Azin Adjoudani 
MHESO 

400 Capitol Square Budding 

550 Cedar Street 

St Paul, MN 55101 

Phone: (6 12) 296-3974 ext. 3418 

Fax: (612) 297-8880 

Adjoudani@heso.state.mn.us 

%tttendint but not appointed member* 

•also on Lamina 2 Committee 
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Mike Barnett 
MnSCU/PALS Office 
Mankato State University 
Memorial Library - MSU 66 
PO Box 8400 

Mankato, MN 56002-8400 
Phone: (507)389-5060 
FAX: (507) 389-5488 

mike@ms.pals.msus.edu 



Patty Biesterfeld 
Assistant Director 
Traverse des Sioux Library System 
1 10 South Broad, Box 608 
Mankato, MN 56002-0608 
Phone: (507)625-6169 
Fax: (507) 625-4049 

palspba@vaxl .mankato.msus.edu 



Michael A. Burke, Ph.D. 

Director of Media and Technology 
Services 

Edina Public Schools 
5701 Normandale Rd. 

Edina, MN 55424 
Phone: (612)928-2580 
Fax: (612)928-2581 

mburke@edina.kl2.mn.us 



Bill DeJohn, Director 
MINITEX 

University of Minnesota Libraries 
S33 Wilson Library 
309 19th Avenue South 
Minneapolis, MN 55455 
Phone: (612)624-2839 
FAX: (612) 624-4508 

w-dejo@tc.umn.edu 



Marsha Fralick 

Minneapolis Public Library and 

Information Center 

300 Nicollet Mall 

Minneapolis, MN 55401-1925 

Phone: (612)372-6650 

FAX: (612)372-6623 

frali001@msusl.msus.edu 



Gary Lundin 
MnSCU/PALS Office 
Mankato State University 
Memorial Library - MSU 66 
PO Box 8400 

Mankato, MN 56002-8400 
Phone: (507)389-5456 
FAX: (507) 389-5488 

gary@ms.pals.msus.edu 



Charlene Mason 

University of Minnesota Libraries 
499 Wilson Library 
309 19th Avenue South 
Minneapolis, MN 55455 
Phone: (612)62+4520 
FAX: (612) 626-9353 

c-maso@tc.umn.edu 



Joan Larson 

Northern Lights Library Network 
P.O.Box 845 
3 18 17th Avenue East 
Alexandria, MN 56308 
Phone: (320)762-1032 
(800) 450-1032 
Fax: (320) 762-1032 

joan@northemlights.lib.mn.us 



Eileen McCormack 
Department of Administration 
Information Policy Office 
320 Cente nnial Office Building 
658 Cedar Street 
St Paul, MN 55155 
Phone: (612)296-1415 
FAX: (612) 296-5800 

eileen.mcconnack@state.mn.us 



Becky Ringwelski 
MINITEX 

University of Minnesota Libraries 
S33 Wilson Library 
309 19th Avenue South 
Minneapolis, MN 55455 
Phone: (612)624-0375 
FAX: (612) 625-3569 

e-ring@tc.umn.edu 



Joyce Swonger 
Director 
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1. INTRODUCTION 

S2SS.CSK 

z&zX&zz. 

[Specifications and related irtiormabon ° The participating libraries 

gateway, are provide in the Request for Pr °P? ^ aut omated library system 

desire a reliable, online, flexible, Sdi^du^ tibraries, formal library 

S-SSSaSSSw* - * - * 

1.2 Objectives , . ctate's libraries, under the aegis of the 

In 1996 the Minnesota Legislature charg c^tpwide online information 

MnLIN. 

The Minnesota Library ££g oTtte sUe^wfiS approP riate 

benefit of Minnesota residents and *««*“ a fuU array of information 

software and technologies, huma P ’ m-. seamless access to high quality 

resources to provide Idinneso^ comum^ ^ co Uaborative and responsibly cost- 
library services in an environmen tQ aC q U i re information and 

effective. This virtual library will all _ regar dless of their needs, life 

knowledge whenever, wherever, and however rega 
circumstances, and individual characteristics. 

The range of educational attainment, 

mera^ng the residents of Mim^m^ tot fw M^^ ^ ated 

i^a;sti ^ «i!scsN 

user support. . 

" 6 “ d 
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Document delivery : resources requested through a commercial vendor or document 
fulfillment service. 

Fully integrated system : an automated library environment in which links between 
functions are seamless and transparent to the user, all transaction occur in real time, 
data is entered once and can be operated on for multiple applications, and actions 
complete in one function must inform or create actions in another function. All 
mandatory requirements listed in this RFP are supported in this integrated 
environment. 

Interlibrary loan: resource sharing between libraries 

Interoperability: the ability to respond to a search request from the client software for 
an item or items known to be in the target database by returning information about 
the result set and to respond to a "present records" request from the client software 
by returning records. 

Local library: any participating library or any member library within a participating 
consortium 

Local loan:, a loan between branches or administrative units of a single library 

Location: an administrative unit, a building, a group of collections (e.g., all reference 
units), or a collection within a building 

Open systems: computer systems composed of products which adhere to 
international and industry standards for interfaces with other products 

Processing unit: a technical services unit that processes materials for one or several 
service points 

Staff person: member of a library's staff, who is able to execute functions and 
transactions in the system to which access is restricted by means of a password or 
other authorization mechanism. [See also authorized staff person] 

User: member of the user community for any participating library 

1.4 Background Information [necessary to revise to reflect actual participants] 

In its initial phase, the integrated library management system is expected to serve 
the needs of XX libraries. A brief description of each library or library system and a 
discussion of unique characteristics, provided by the participating libraries, follows. 
Additional information about participants may be found in Appendix A. 
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Participants include individualhbranes b tfjf vendor may assume 

siS*£ , S£S^'SiEr— i —— - 

may operate autonomously. 

In general, the system is expected to operate efficiently m an environment 
any participant can 

(1) establish its own operating policies and procedures through independent 
profiles, 

(2) control use of the integrated library system through independent password and 
authorization functionality, and 

(3) control access to certain files through independent password and authorization 
functionality . 

At the same time, it is manda^ that the ' 

holdings and authority recorcU) fui^«y thT swtem function in such a 
libraries. In other words, whde it is itablish its own operating 

way that each library, consortium or oth 5f f r . P l j internal library functions, it is 
policies and can control access to ^“T^S^dthe cirodation status of 
essential that the information concerning th.,^ S g ^ visib i e f rom any 

pC-d system, regardless of its location. 

The system is expected to aUowMC* The 

S^^on ^“i^teffand users on demand in real time. Describe how 
this will be accomplished. 

hS standards (a brief descriptio^f«q^dl» 1 '^“^ 0 ™p“5bc e ^ n W 

standards to be added later and a co P future which is open; i.e. 

The vendor proposal must .!^“ d * a J ^ on commonly accepted practices, whne no 
standards-based, when available, or bas multi-tier < client-server 

- 1 — 
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The State of Minnesota has established a Library Planning Task Force that reviews 
all library technology projects to assure that these projects meet Legislative Goals. 
Six factors are considered by the Task Force: 

• Standards-based: Libraries should only invest in systems that are 
standards-based, to prevent problems in the future with transmitting 
or exchanging data and also to enable easier integration with future 
developments. 

• Open: The architecture and underlying protocols and software should be 
open. 

• Functional. Technology systems should support an integrated 
approach to library processes (input once, use many). 

• Network-based: Technology systems, including downloading and 
printing capabilities, should integrate easily into the networks in place 
locally, regionally and nationally and work across network 
architectures. 

• Virtual: The information systems should be capable of interacting 
with other resources in such a way that a "virtual electronic library" is 
created for the user no matter where the data are located. 

•Future-looking: Vendors should be willing to experiment and 
partner with the users, have appropriate methods for receiving user 
input about needed functionality, and use this information to help 
shape future enhancements. 



2. Instruction to Vendors (more to be added later along with state language) 

• affirmative action certification of compliance 

• certificate of insurance 

• Minnesota tax ID number 

• affidavit of non-collusion 

• who to contact with questions 

• number of copies of proposal required 

• Each respondent must describe in its responses to each specific requirement how 
the proposed system meets these requirements. Each respondent must specify 
clearly which parameters have system-wide application or forces and which data 
must be shared on a system-wide basis. 
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• Mandatory system requirements we * 'dSioi ted 'by^ ftetrm "It is expected 
other (ie. desirable) system capability ae does not sat islactorily meet 

Sto^SXmaTL^T^tdter ^deration. 

For eadt capabiUty the system vendor must indicate whether the system: 
l compS««pt for specific elements (to be named/described) 

* B N ?taTrians a to become compliant by a specified date 

to „ 

bothmandatory and desired capabilities. 

3. Evaluation of Proposals (more to be added later) Task Force< Hgh er 

Proposals will be evaluated by menfcera of It is the goal 
Education Services Office, and represents P ^ J* tes a forward looking 

to contract with an automated ?y st f”«"t^Ts wooing in areas such as 
approach to development and un P 1 ™® nl ® matching, and electronic commerce, 
artificial intelligence, relevance ranking, fuzzy matching, an 

as they become feasible in library systems. 

Factors upon which proposals will be evaluated include but are not limited to th 

f0U0W if Understanding of scope and objectives 

• approach and deliverables 

• qualifications of company and personnel 

• cost 

Conditions (more to be added later with state language; see attachment 4) 

• state right to reject any and all proposals 

• cancellation 

• audits 

• data privacy/ data practices act 

• intellectual property/ovmerslu^ their product 

: K *.*-,-*" 

. provid a eTust^1ib“whl wS# Om have been converted 
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5. Mandatory System Requirements 

The features described in this section are mandatory; that is, the vendor must be able 
to offer all of them. Any vendor who is not able to demonstrate compliance with 
these mandatory requirements may be excluded from further evaluation. In the 
case of emerging standards, noted as such in Appendix B, if the vendor is not fully 
compliant at the time of response, the vendor should provide a "plan for 
compliance" which specifies the date by which the vendor will be fully compliant 
with each element of the standard not currently supported . 

The system shall be a complete system, which is defined as the applications software, 
software installation, database loaders, training, documentation, maintenance, and 
ongoing software enhancements necessary to provide easy-to-use online real-time 
integrated automated support for the following functions: 

• online public access catalogs, including union catalogs for consortia 

• authority control 

• circulation control, including both electronic reserve services and traditional 

reserve services 

• database maintenance and cataloging 

• acquisitions 

• serials management 

• binding control 

• fiscal management 

• interlibrary loan system 

• inventory control 

• management information 

• integration with other automated systems at the local library level 

• linkages with other bibliographic databases and full-text, numerical, image, and 

multimedia databases 

• booking system 

• interfaces with vendors systems 

A system that uses PC-based software for a function, such as acquisitions, and 
updates the catalog database by means of periodic uploads of the PC files will not 
comply with this mandatory requirement. 

5.1 Technical Requirements 

5.1.1. Open Systems/Standards 

5. 1.1.1. The system shall use common user interface standards. Screen scraping 
technology is not acceptable. 

5.1.1.2. The system shall have an fully-functional integrated extension to HTTP 
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or its successor technoloCTjn order to use J^remote access via 

5 . 1 . 13 . The system is expected to be object-oriented or object based. 

5.1.1.4. The system shaU interface with common applications development 
platforms/ tools . 

5.1.1.5. The system is expected to be DCE (Distributed Computing Environment) 
compliant. 

5.1. 1.6. Vendors shaU specify SSh^toraUty desired 

which platforms would be most likely to supprart uwio 

byS participating Ubraries with an appropriate response time. 

access to that server for all purposes. 

^es"" '£££££» 

specify how this protection might be assured. 

5.1.2 Client Server Architecture architecture, which is 

5.1 .2.1. The system shaU support an op^ / standards ot/ w here standards 

portable and interoperable and whidr depend p architecture * to be defined 

are lacking, commonly accepted P r ^ ces * syste m will put highly shared 

by the system vendor, we anticipate that PP^ servers and data access 
activities and resource-intensive while placing 

activities on database servers (us g ' activities on the client. The system 

presentation activities and highly between clients, and 

client upgrades from a central server or 

to run them from a network server. 

5.I.2.2. Staff in-library clients stall be public use. This 

the participating Ubraries depending upon local choice. 
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5. 1.2.3. The system shall support at least one client which can be used in dial-access 
situations. 

5. 1.2.4. The system shall support at least one client that is compatible with standard 
adaptation products used by individuals covered by die Americans with Disabilities 
Act. 

Given these clients, respondents shall describe minimum hardware requirements 
and software requirements for the desktop computers to be used as devices for the 
system. 

5.1.3. Relational Database 

A highly-supported relational, or object-oriented, or highly supported database 
management system shall be part of the system 

5.1.4 Network Connections 

5.1.4.1. The system shall operate within a full TCP/IP environment, including 
Telnet, FTP, and SMTP. Connections are required to backbone networks and to 
local area network infrastructures for the system's online data communications 
with data input and output devices, including computers, printers, and those 
devices that are capable of displaying and inputting the full AT .A character set or the 
UNICODE set. 

5.1.4.2. It shall be possible to use desktop computers, including PCs running 
Windows, version 3.1 or higher, communicating with the central site(s) hardware 
via the network infrastructure, as devices for input and display for the system. 

[The preceding item must be reviewed immediately prior to release of the rfp .] 

5.1.4.3. Respondents shall specify in their proposals how the requirements of this 
section will be accomplished and shall identify in the proposal the cost of any host 
or server communications hardware and software that will be required in order for 
the proposed system to comply with this requirement. 

5.1.5 Security and Backup 

5.1.5.1. The data security plans for MnLIN are to provide access to secured data, 
databases, and services through implementation of authentication technology that 
will ensure secure computing environments for customers and institutional data. 
The system is expected to support this option. Vendors should describe how they 
provide security and authentication other than through the use of the patron file. 

5. 1.5.2. The system shall provide authentication and account profile 
systems to limit access to certain records, fields, and functions to authorized 
personnel or workstations. The system shall accommodate multiple levels of 
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security and attow for different levels of authorization to be associated with the 
same staff person for different subsystems. 

from erasure or damage due to accident, 

error, or through deliberate action 

provide factions lowing accidental or deliberafe 

• provide for forward recovery of all transactions from a specified point 
. “?oZSTaL 0 “ 8 i transaction backout) for failed or interrupted 
transactions 

The vendor shall specify how each of these tasks is accomplished, 
to another or closing a work session. 



5.1.6. Imaging Directions Worrf . arirtn with wm imaging systems and to 

^eVrthp^defX a^£° “spouse capabilities, is expected to 
interact with local voice response systems. 



[Th^vendcu ^jditioiTto d^^btag* ^d^opm^*™^* thTvSdor 
development process. In addition to descnbmg resD £ nd to input from 

libraries have if the vendor chooses not to 

implement requested enhancements? 

a- - — — “ fc ^^5*'ES£1SES. 

- rJ- «■— "» “ 

that MnUN may contact them. 
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5.Z2.6. Given appropriate terminal hardware and software, it shall be possible to 
“5; °A-' st ° re ' dis P I fy (in proper relationship to other displayed characters), 

dlaCI ? tlCal 1 m ?5 ks 311(1 other characters that comprise the ALA character 
ff r * ach ^ s P°ndent shaU state whether any special termini hardware or software 

t, r%Jn ed J 0r bea ring in mind the mandatory requirement for 

CP /IP network. If a system has this capability, it is assumed that the bid price 
includes the cost of any special software that might be required. 

[The preceding item should be reviewed immediately prior to release of the rfp] 

5.2.2.7Given appropriate terminal hardware and software, it shall be possible to 

ex P°. rt ' store, display (in proper relationship to other displayed characters), 
and edit all diacritical marks and other characters that comprise theUNICODE 
orldwide Character Standard, Version 1 and new versions as approved. Each 
respondent shall state whether any special terminal hardware or software is 
required for this capability, bearing in mind the mandatory requirement for TCP /IP 

network. If a system has this capability, it is assumed that the bid price indudes the 
cost of any special software that might be required. * 

[The preceding item should be reviewed immediately prior to release of the rfp] 

system shall support at least one client that is compatible with standard 
adaptation products used by individuals covered by the Americans with Disabilities 



5*2.3. Record Creation and Maintenance 

5.2.3.I. All record creation and maintenance transactions shall occur in real time. 

5j2.3.2 The system shall support the creation of a bibliographic record, whether it is 
created online or as a result of data transfer from an external source, to which an 
order record can be associated. 

5.3.3.3. The system is expected to store and maintain for each library its bibliographic 
data including all institution specific data in USMARC format and display that P 

formation to each library's staff and users on demand in real time. Describe how 
this will be accomplished. 

5.2.3.4. The acquisitions subsystem of the system shall utilize the system’s 

ofbS^uc a ^or1s and ^ re<IUire U ' e Creati0n ° r matatenanCe ° { a “P" ate 

513.5. The system shall be able to receive and process electronic transmission of 
acquisitions data, including approval plan information. 

MthtdTlsYcen^" StMe ' ““** cakulations ' «« <*P > a X dates in the 
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52 . 3 . 7 . It shaU be possible to copy a single bibUographic USMARC record from one 
library to another. 

5.Z3.8. The system is expected to dynamically delete or undelete bibUographic 
records from sn institution. 

5 2.3.9. The system is expected to maintain a history of edits for each Ubrary's data. 

5.2.3.10. The system isexpectedtoe^tandpro^ labels ' 

single and multiples, in formats compatible witn ioc v 

5.2.4. Interlibrary Loan and O^ument Delivery standards, 

5.2.4.1. The system and ISO 

toterUbrar^Uran Standard Frot^^!^ J^^g^^g'^^^UtterUbmry^ Loan 1 Data 

5 2 4 2 The user request interface shaU display an i^tituttor^p^ed copyright 
^om^S ^before allowing the request for a copy to be made. 

5.2.5. Item ID Numbers and Patton ® Numbra existin item identification 

5.2.5.1. The system shaU be able , to . jnhSefit in those numbers. 

numbers, including the ch * ck 'f l ®“ d * L p die capabfiity to calculate the check digit 
CompUance requires agreement to develop tne capao y 

ofL identification numbers and the check-digit atgorithms.) 

fi.e.^CODABi^mtd^Cofifi 6 ^ 

S.2.5.3. The system shall prevent duplicate item identification numbers from being 
entered into the database. 

Compiiance^equttes^^eement to SSpt^ 

{£££ 5tt"pSca,ions of participating libraries' patron identification numbers.) 

5.2.5.S. The system shaU prevent duplicate patron identification numbers from being 
entered into the patron database. 

5.2.6. Call Numbers 
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«= call numbers, 

numbers, ai^local'call niimh^n caI1 ^ lu f lber \ ^ document numbers, SuDocs 

sheliUsting^ffid^t s^g 5 ^ 6 ^ done *» 

for S * h l a S li « ty *° 8tore and 'teP'W different call numbers 

Ti. _l ii . , & pbic item, both for a single location and for different locations 

Sr -r^ 10 8tore multi P le bibliographic records forXSme 
bibliographic item m order to satisfy this requirement. 

52.7. Subject Headings 

editing acce P^ support and maintain storage, retrieval, display and 

SSSSSSss^^^* 

5*2.8. Database Integrity 

T?* SyStem sha11 P revent more than one staff person from beine able to 
modify the same record simultaneously. 8 to 

®f. 8 - 2 - I ' sha ^, be Possible to block staff functions for unauthorized nersons from , 
dedicated public access terminal or from a remote public arn^LfoT °“ 3 

52.9 Draft Standards 

^X er f° r r haU demonstrate a commitment to comply with the fbUowine 
standards when each is approved by the library community 8 

FOT ea *:tu y ar co^liant em VendOT mUS ‘ tadiC3te Whether ““ W 

‘ k KpS' fOT SPedfiC elementS (t ° be name d/described) 

- has plans to become compliant by a specified date 
" NO plans to become compliant 

both 1 i? If? P 0881 ^ 1 *' responders to this RTP should describe HOW they achieve 
both mandatory and desired capabilities. y acmeve 

5.2. 9.1. 239.71-199X (Holding Statements for Bibliographic Items) shall definp Hata 

5.2.9.2. Z39.76-199X (Data Elements for Binding of Library Materials) shall Hofino 
bod, required and optional data elements thatL, be u^d fo“ii g rLor^to 
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enable automated library systems to communicate with a bindery's automated 
system. 

5 2 93 Z39 69-199X (Patron Record Data Elements) shall define the data elements 
toffh^L mduded in a library's circulation system to create a library patron 

record. 

q 5 9 4 Z39 70-199X (Format for Circulation Transactions) shall define the 

SS222E ‘used whan “^“h^a^ns 

files (bibliographic information, holdings descriptions, and p i 

aes SSon information, patron accounts, patron requests for unavailable 

items, and scheduled reservations or bookings). 

6. Desirable System Capabilities 

Vendors^shalf s^Sty d^riy which parameters have system-wide apptication or 
forces and whichdata shall be shared on a system-wide basis. 




il.l. S Th^stem is expected to indude a flexible multilevel staff person 

uthorization control capability that: oerson to examine and 

makes it possible for an appropriately authorized staff ( person nm 

Iter the authorLtion levels for other staff persons m a group of hbr^es or g 
needing the assistance or involvement of the vendor or central 

yS,e Vo^SrL“ablish and maintain a separate set of passwords and 

- 

excluding staff members with authorized administrative or funchona 
. rSheTit'optional to enable or prevent a staff person to on^essing unit 

JSSaS Td^^ot - an item 

that is located in a different library , , . delete 

. makes it possible to restrict a staff person to the ability to alter or de 

records from a single file, e.g., holdings records; 

• makes it possible to limit authority for work on authonty records, 

holdings records, 

serialscontrol records, circulation records and ILL records by library or by 
group of libraries. 

6 1 1 2 In to password control for the library application software, the 

system's^paatog system is expected to prevent unauthonzed access (either 
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external or internal access) to system management functions and files. Describe how 
tins is handled in the system. 

6. 1.1. 3. In the event of a hardware or software failure that damages one or more 
system files, the system is expected to provide a method of restoring the system 
database to its state of existence immediately prior to the event that caused the file 
damage. 



6. 1.1.4. The system is expected to include capabilities to control and manage large- 
scale printing operations so that data communication problems will not result in 
the loss of output and that output will not have to be regenerated, even when the 
printer is remote from the central site computer (see Section 8.3). 

6.1.2. Profiling 

6.1.2.1. System parameters and options are expected to be available interactively for 
addition, deletion, and change by an authorized local system administrator or 
designated assistants). These include but are not limited to: 

• operator security authorizations 

• OPAC menu and screen text 

• OPAC record display formats 

• search command parameters 

• record export formats 

• location names and parameters 

• acquisitions and cataloging parameters 

• circulation policies and calendars 

6.1.2.2. Online tables are expected to be designed to expedite efficient and consistent 
data entry. The table structure is expected to: 

• support queries on individual table values or a combination of values 

• allow for a global replacement of a specific value in individual profiles 

• allow the system administrator to copy or point to an existing profile 

• provide tools or reports that assist the system administrator to 
maintain consistency in a set of profiles. 

6.1.3. Flexibility 

6.1.3.1. The system is expected to exhibit consist and uniform (a) screen design and 
(b) methodology of using the various modules and functions in the system along 
with flexibility and ease of use. 

6. 1.3.2. Consistent with security considerations, the system is expected to allow 
library staff members to move easily from function to function and not lose work in 
progress. 
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613 3 The system is expected to allow staff members to toggle easily from staff 
SJpS and from public mode to staff mode and between modules 

while displaying die same record. 

6.I.3.4. Consistent with security considerations, the system is expected to imake t it 
possible to search any indexed record field while performing any function in any 

place within the system. 

6.1.35. The system is expected to be available 24 hours per day 7 days perweek with 
98% reliability, and it shall not be necessary to make the system unavailable to 
public and staff persons nor should response be degraded when P erf °J^S , 
routine system management activities as file backups, file loading, and notice and 

report production and printing. 

613 6 When the processing required for an online transaction exceeds five (5) 
seconds the system is expected to display some kind of information or indication 
that transaction processing is underway. 

6. 1.3.7. The system is expected to interrupt a long search with options to revise, see 
partial results, continue, abandon the search, etc 

6 1 3 8 In displays involving long lists of records, such as a serials title with a large 
number Sitem rTords, the fystem is expected to navigate within the list easily and 
randomly, to reach the beginning or end of the list with a single transaction, and to 
display any specific records in the list with a single transaction. 

6. 1.3.9. The system is expected to make it possible, without havmg to reload the 
entire catalog database, to add bibliographic records and/or holdings records for a 
library that was not represented in the database when it was origina y ere 

6 1 3 10 When adding bibliographic records and/or holdings for a new library/ jhe 
system is expected to "exist tolntegrate those bibliographic 

with those of other libraries or to load them as a separately searchable database. 

6.1.3.11. The system is expected to create a new index in a file without having to 
reload the file. 

6.1.3.12. The system is expected to support dynamic indexing of all records including 
unlinked records. 

6 l 3 13 The svstem is expected to add indexes, add data elements to existing indexes, 
^dde^ indexes, without completely regenerate* 

indexes. 
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6.1.3.14. All search methodologies are expected to be available in both public and 
staff mode subject to security requirements. 

6.1.3.15. The system is expected to allow individual libraries to decide which system 
modules to implement and when to implement them. 

6.1.4. Reporting (See also Section 6.7— Management Information) 

6. 1.4.1. The system is expected to include a report generator that features: 

• selection of any field from any system file for reporting 

• use of Boolean logic in selection criteria 

• reporting of data from both fixed and variable fields 

• sorting for all fields 

• provision for totals in detail or in summary 

• combining in one report information from more than one file 

• relating of current activity to activity from previous period 

• retention of generated statistical information and ability to use such 
generated information in subsequent reports 

• retention of report formats for later recall by user interactive editing 

facility ° 

• reports in electronic and print output formats / any of which can be 
customized and/or formatted for further analysis including ASCII, 
commonly accepted spreadsheets and database formats 

• reports from different time periods with capability to then have the 
information compared and related. 

6. 1.4.2. The report generator is expected to feature an easy-to-use interface for 
designing and formatting reports and be designed in such a way that it can be used 
by library staff with a minimum of training. 

6. 1.4.3. The system is expected to be capable of having certain reports produced 
automatically on a library specified schedule. 

6. 1.4.4. The system is expected to have the capability to print transaction-related 
output, such as due date slips or save shelf slips, and management reports on 

a printer located in the library where the transaction is performed or from which the 
report is requested or generated. 

6.1.4.5. The system is expected to maintain a transaction log, which can be analyzed, 
that records the date and time of each transaction on the system, the workstation for 
wluch the transaction was processed, the type of transaction processed, and the text 
of tt\e transaction if consistent with a time period specified by a library. These 
reports may be generated by authorized staff at the local library. 

6.1.5. Customizing 
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6.15.1. The system is expected to make it possible to customize system-supplied error 
messages. . 

■******" 

6.I.5.4. The system is expected to aUmir ^^^^o^ffl^«* eau,ho^iz ? ,ions, 

— * such - 

timeout periods. 

61 m ■ •'"T CSSlS SfS^tSl'^ord rfcp^rmft, 

^a^ta^C^ace, and terminal settings. 

6.1.6. Financial AccounUng f or Users for mi tracking up to 50 

delivery charges, processing charges. 

6161 UKOtd mpi.? f “ UM ' ? ' BpwWMwSSrttol on Ih. 

S3RBS - *«■*-. 

libraries.] 

6.1.65. The system is expected to aUow authorized staff to alter records by addmg or 
canceling charges. 

"^bTt^ m P r 

6.1.65. The system is expected to make it possible to distinguish user charge by 
library. 

spe^c^^S'ofo^f slrS^Sitsby libra^^d by^tyT^o^drtW andcreditwith 

appropriate aggregation of amounts. 
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“jKJfj system expected to provide data fields that can be used to maintain an 
audit trail for receipting cash. 

6.I.6.8. Jhe system is expected to interface financial transactions with other financial 

transaction and accounting systems at participating libraries. 

6.2 Online Public Access Catalog 

delaying recorS ibCS SySt6m Capabilities havin g to do with searching for and 

Each vendor shall describe the capability of the system to meet the following 
searching components: & 

A spell checking feature to identify incorrectly spelled words and give 
suggestions to other possible spellings. This feature should be subject to be 
enabled/ disabled at the user's option. 

Users' ability to enter searches in question format through the system's 
natural language ability. This feature should be subject to be 
enabled/ disabled at the user's option. 

• Thesaurus feature incorporated in the subject/subject keyword headings 

searches. This feature should be subject to be enabled/disabled at the user's 
option. 

* Users' abiUty to search at multi-level knowledge levels. Users should have 
uie ability to choose options (beginner, intermediate, advanced) at any time 
during the search with screens and commands to adjust accordingly. 

wt* ’t®? des f? be ” ** «"««« to which its system functions 

with respect to each desirable capability described in the numbered sections below. 

6.2.1. Searching 

6.2.1. 1. Regardless of the file structure used by the system, the online catalog is 

expected to allow records for all libraries in any group or consortium to be retrieved 
in a single search. 

6.2.1.2. The system is expected to maintain a search history, with numbered sets that 
may be used in later searches. 

6.2. 1.3. Each set in a search history is expected to indicate the number of hits 
associated with it. 

6.2.1.4. The system is expected to make it possible to limit a search in various ways 
fe.g. by date or range of dates, language, country of publication, and type of material). 
This is expected to include the capability to limit by more than one parameter (e.g. 

an g ua ge arid date) as well as the capability to specify more than one value for a 
parameter (e.g. French or English). 
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6.2.I.5. -me system is expected to provide dear user prompts at each stage in a search. 

ap^oVda^ id^g^ problem. 

6.2.I.7. The system is expected to provide a context-sensitive help system for all 
functional modules of the system. 

^ p^i^^lt £ e^cfedTo f^ia^s'r^on of 

locally developed tutorials. 

6.2.1.9. The system is expected | e * w^ge PllSesp^y languages 

lupl^d «”^S^y wwch SSU language interfaces ate supported. 

6.2.1.10. The system is expected to allow foe user to use search commands to bypass a 
series of prompts or menus. 

6.2.1.11. The fields and subfields to be indexed for all types of searching are expected 
to be locally configurable. 

S^X^^ed^o^ te ^ttarZfa^ffield 

in a simple manner will be available. 

6.2.1.13. The system is expected to support right-hand and internal truncabon of 
keywords. 

6.2.1.14. The stop word list for keyword searching is expected to be configurable and 
changeable by consortia or local libraries. 

6.2.1.15. When a stop word is used in a search, foe system is expected to alert foe user 
with an appropriate message. 

6.2.1.16. Keyword searches are expected to be able to use Boolean operators (AND, 
OR, NOT). 

6.2.1.17. Keyword searches are expected to be able to use positional operators (e.g., 
ADJ, NEAR, WITH). 

6.2.1.18. The default operator for keyword searching is expected to be locally 
configurable. 
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6.2.1.43. The system shall allow nested search sets. 

6-2.2. Displaying and Manipulating Output 
Describe the capability of the system to 

• implement a relevancy ranking feature as a "sort" option when displaying 

search results r J ° 

* provide a graphical call number locator which would offer the option to view 
a map of the library's location of the particular item. 

6.2.2.I. The user is expected to be able to select an alternate display format or set a 
new default display for a searching session 

6.2.22. Displays are expected to be dearly labeled, with the text of the labels 
determined locally. The MARC protocols for tags and indicators are expected to 
determine what is encompassed by each label. 

6.2.2.3. Any displayed list of headings is expected to indicate the number of 
bibliographic records assodated with each heading. 

6.2.2.4. The system is expected to display, add and configure text for printing; and 
print, download, or E-mail any specific record, group of records or f ull text. This is 
expected to indude the capability to mark specific records for action and the ability to 
specify any of several formats, e.g., EndNotes, Prodte, MARC, etc. 

6.2.2.5. The system is expected to make it easy for users to name individual print jobs 
and route them to a specific networked printer. 

6.22.6. The system is expected to be able to sort search results by any of a number of 
fields. 



6.22.7. The system is expected to allow local options to sort items for display. 

6.22.8. The system is expected to display multiple items (for example, copies in 
different locations of the same library) on a single screen. 

6.2.2.9. The system is expected to provide receipt information for individual current 
issues of serials in OPAC displays. 

6.2.2.10. The system is expected to display status information whenever item level 
information is displayed; such statuses include "On Order," "In Process," "On 
Reserve, Missing, Charged Out," "At Bindery" or similar language. 
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that item is expected to be displayed on each record. 

6.2.2.12. The system is expected to give status information without requiring 
user to move through multiple screens. 

tSBB£&K^SKr«* sa34: - 

system should also display the time an item is due. 

6.2.2. 14. A display of items with a status of "Missing" or "Lost” is expected to 
indicate the date that status was assigned. 

6.2.2.15. In displays for items charged out, the system is expected to show th 
number of recalls or holds for the item. 

6.2.2.16. The system is expected to support die display of full-text documents 
variety of formats. Please specify formats supported. 

6.2.2.17. The system is expected to be able to search for and deliver non-print media, 
such as audio and video. 

6.2.2.18. When full text is available for a citation, that information is expected to be 
clearly evident on the display screen. 

6.2.2.19. The user is expected to have die option of a non-labeled display versio 

6.2.2.20 The system is expected to have the capability to save the output of search 
sessions. 

OPAC is- locally 

. D*“ibe n thecapabilities of the system to link from: one function to another, 

a bibliographic record to an Internet site; from an arbde 
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tation to local or consortial call numbers, holdings and circulation status 
• 5SSjP ; 4 J nd fro ?! .. a .bibliographic citation to an image or multimedif 

escribe die capabilities of the system to search and display results from more 
than one database outside this system simultaneously. 7 
Desaibe how users can search the local catalog, Usenet groups the Web 
d/or journal databases from the same search statement aMhe same time. 

6.2.4. Locally-Mounted External Databases 

In addition to providing access to databases via gateways the svstem ic 

sa asa * -"** •»«*» - ajss ss'vssr 

* eXpeC * ed *° Ioad records OT BRS format from 

bridses from 8,6 ^ 

S^dtotaST * eXP6Ct6d 10 l03d ' St0r6 ' and “** fuU -* ext tesmmes to eternal 

63 Circulation 

Sfa^" 6 ^^ 6 ” ca P abmBes that have to do with the circulation of 

™ M e Hb ‘™^ ary Ta S ' inCludin S «» mana gement of items placed on 

' t d I b y Ioan ^ document delivery functions; and the management of 

JSSi Each « s P° nd ®‘ =haU describe in detail th e 

ts system functions with respect to each desirable capability described below. 

6 3*j i (Charge ' Dischar S e ' Holds, Saves, Recalls) 

63.1.1. Withm administrative unit constraints, it shall be possible for a user to 

charge or renew items from any library within a consortium A user shall notn^ 

Pa,r0n l °- *° 156 3bl6 * it^T^ EESE? 

[NOTE THE POLICY IMPLICATIONS OF THIS.] 

6 , 3 ; 1 - 2 - ®y stem . is expected to alert the staff person whenever an item that has a 

status of lost or missing appears in any online transaction. 

system iS expected to mak * » possible for a patron, upon appropriate 
n "*l" d< f tlon to us ? a current ID card to charge out materials at OPAC P computers 
pe purpose arc ahon terminals. If this option is supported, the system is 

4 C 
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.y jasjsSL.n 

devices for participating libraries.] 

63.1.4. The system is expected :*^*^^^^Smnftetatt6UiSn g charge 
its check digit when scanning identification num number, 

and discharge and from the P^ on .^^^.“ ^ periling the charge or 
the reason for the error should be ^rorta the barcode, please 

discharge. For example fatal error ta the 

^ode^'^'rste £5Lito charged, their materials, the message should 

indude user options to remedy the error. 

63.1.6. When the user ID is entered intotasystem, ^-^neT^or 

i-W toadert die staff person or block 
the self-charge process during die course of the transaction. 

63 . 1 . 7 . The system is expected to allow authorized staff to manually restrict 
individual patron activities* 

63.1.8. The system shall allow aitaiimstrativeimiBo^ to restrictions 

implement restrictions on patron records to alert the staff person to 

during the course of the transaction. 

6.3.I.9. The system is expected to make 

sssr. — - - 

2 ZSiZ,, „Md> md «=». pS-l W ■ “~~ 
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user interface is expected to provide a reminder to the user to sign out once all 
requests are placed. 



6.3.1.12. The system is expected to make it possible to review online the list of 

uncataloged charged items and browse backwards and forwards in that list by title or 
other index points. 

6.3.1.13. The system is expected to make it possible to use circulation functions to 
temporarily relocate an item to a different circulation unit or location, to circulate 
that item to borrowers from its temporary location, and to have the displayed 
location of the item reflect its temporary location. This function is expected to be 
available for use on individual items or for a range of call numbers. 

6.3.1.14. The system is expected to make it possible to create temporary locations 
either at the item or title level. 

6.3.1.15. When a given item is associated with more than one related bibliographic 
record (e.g., a serials record and an analytic record), changes in status and location for 
that item are expected to be made in all associated bibliographic records. 

6.3.1.16. The system is expected to allow an authorized staff person to key in a 
borrower record at a circulation point. 

63.1.17. The system is expected to perform a charge transaction, for example by 
choosing the borrower record from an index display or by checking the item 
out without exiting the borrower record, with a minimum of keying even when the 
borrower does not have an ID card. It should be an option at the local library or 
consortium level to require an appropriate ID. 

6.3.1.18. The system is expected to to complete a charge transaction easily and with a 

minimum of keying even when the item being charged is not in the catalog 
database. 

6.3.1.19. The system is expected to maintain information concerning scheduled 
open hours for each participating library and consider this information when setting 
due dates, times for charged items, and in calculating overdue fines. It should be 
easy to override dates, times, and fines calculated via this function. 

6.3.1.20. The system, when charging an item out, is expected to determine the due 
date/time for the item by considering the borrower category, the type of material, 
and the location of the item being charged as well as the time of the charge and the 
building schedule for the location from which the loan was made. 
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63.1.21. Hie system is expected to sud^s'ttie'^oTS^ 

from hourly through loan periods defined by a flxed date, 
academic semester or quarter, through indefinite. 

Optimally the system is expected to disp ay P nmvided during the check in 

seven pads). l*us information is ®*ert£ tod. o bepnvg ed 

absence of a 4sing item as they complete the check-out 

63.1.24. During the course of a other° W *** 

authorized staff person to easily search foran H borrower’s fine 

SSSi‘S» XSStSZi S= »-«..■> 

number. 

6.3.1.25. The system is expected to al low P^^Sde ^ btodjng 7 

cS a omSothe e ™S“woIild prevent the ^8°'““* SSed'S’fte “ 
gSta ^" e to otrfde'SS’ and“restrictions on patron activities 
Sbe protected ttoough the level of staff authonzabon. 

ss?.r-,rjss s.“sss“ • — 

63.1.27. The system is expected to allow borrowers, upon appropriate ^ ubrary or 

r^etcest '^^ace^x^ P~v^ a re^er to the user 

kkvss isx ssssnsrjs- * • — 

tone telephone. 

m^L^edbl^sl 2 rSg^"/ 

holds or recalls by other borrowers. 
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til' 29 ' 1 £ e S X ste J n is ex Pected to allow an authorized staff person to determine to 

item charged, the date P and ?ocatio“ 
dwge and each renewal Providing the time of the charge is desirable for reserve 
materials and optional for other materials. reserve 

6.3.1.30. The system is expected to allow display of a list of items charged bv anv 
borrower or a specified proxy borrower ID cnargea Dy any 

iS eXpeCte , d '? calcuIate immediately and automatically 
upon the discharge or renewal of an item. * 

6^3.132. When a charged item is discharged, the link between the borrower and the 

orrowed is expected to be retained for a locally-specified period to allow for 

"STS f ^ pa A ^° n assi ^ responsibility for ^nagedTateri^ or ncm- 

P J 6CeS < ^ 4116 ** shall be broken permanently, but file 

date and location of last return is expected to be retained. 

[THIS MAY BE A VIOLATION OF DATA PRIVACY LAW; NEEDS CHECKING] 

6.3.1 33. The system is expected to alert the staff person, before completing the 
d^charge of an item, to check for the presence of all pieces if there £ more than one. 
seven Darts') C Th Ste f ex P ecte< ^ to display a description of the pieces (e.g. score and 
is missing. ^ Staff “ ex P ected to be abIe to cancel the discharge if an item 

63.1.34. The system is expected to be able to flag an item, which lacks a part with 

,0St/ ° r Claims retumfi4 “ d is ex P“ ted *° - t the 

Whan 8 charged item is discharged in a location or circulation unit that is 
admSiS^ 1 ° C ° r '- * e s l s,em is “Pected to be able, at the option of the 
^TSm bo"d ge * e item “ d b,Bak link b “ «« borrower 

hnmff™-'K hen .r item b discharged in a location or circulation unit that is not its 
SyS u em “ expected to alert the staff person of the proper routine 

S ^arge^r ^ kHmU ^ “ reaches its home Merton and 

taH L to "of^;, 0 make * to P‘ a “ a Md « « - 

ftem. 38 ^ SyStem “ ex P ected to allow authorized staff to change the status of any 
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6.3.139. The system is expected to allow authored staff to create a list of items that 
have been in transit for a given number of days. 

“sarrMS fjfttasr-- - 

still charged to a different borrower. 

6.3.1.42. Hie system is ( expected to « ^^ ri ^ a ^^^ g S ^fi^ S for an overdue item 
effective date of a discharge and to override the levying oi 

at the time of the discharge transaction. 

6.3.1.43. During a discharge ^ 

of a hold or recall on an item and alert th P e . r . wor j cs tation and the borrower 

*■* - “« 18 avaUable to be picked up - 

63 . 1 . 45 . The system is expected to allow an authorized staff person to force the hold 
or recall of a charged item at any time. 

63.1.46. The system is expected to automatically notify a borrower when an item 
charged to that borrower has been recalled. 

6.3.1.47. The system is expected to generate recall and hold notices automatically. 

63.1.48. The system is expected to have The^parameters 

^^e^^nrftoe dfe date SHOULD consider both the location of 
L material, type of material, and the borrower category. 

6 3 1 49 The system is expected to allow authorized staff to determine which 
Sa^smLteSls may be P routed to for borrower pick up. 

6.3.130. The system is expected to make it orta 

to place a hold or recall on an item that “ *1 ,^ p Nation based upon the 

or recall queue. 
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63.1.51. The system is expected to make it possible to provide a report that lists all 
items presently being held for pickup at a given location for the purposes of 
verifying that items have been routed properly to that location. 

6.3.1.52. The system is expected to allow an authorized staff person to change the 
expiration date, the pickup location, or the hold or recall queue at the time the hold 
or recall is placed or at any time thereafter. 

6.3.1.53. The system is expected to allow a hold or recall on either a specific copy or 

on the first copy returned. rj 

63.134. When an item that is not charged out is declared to be missing, the system 
is expected to identify the item as missing and initiate the automatic production of 
search notices. The system is expected to allow authorized staff to request lists 
arranged in shelf-order of lost and missing items by location. 

63.1.55. When an item has been identified as missing, the system is expected to 
allow a hold on the item. r 

6.3.1.56. The system is expected to alert the staff person or borrower if a borrower 
attempts to place a duplicate hold or recall or to recall an item from himself or 



6.3.1.57. The system is expected to have the capability to recall automatically a 
charged item based on library defined criteria, borrower type or other defined 
conditions. The number of holds or recalls that triggers a recall is expected to be 
consortium or library-specific. 

6.3.1.58. The system is expected to allow an authorized staff person to cancel a single 
hold or recall or to cancel all holds or recalls on an item and notify the patron. 

63.1.59. The system is expected to automatically cancel all holds and recalls on an 
item that is recalled for reserve or that is declared lost 

6.3.1.60. The system is expected to automatically notify a user who has placed a hold 
or recall when a hold or recall is canceled; the notification is expected to include the 
reason(s) for the cancellation. 

6.3.1.61. The system is expected to offer the option for library patrons to place holds 
and recalls within established guidelines on charged items without library staff 
assistance and to designate a choice of pick-up locations. 
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of time. 

6.3.1.63. The system is expe^edto 

used to charge, renew, and discharge items lan _ sys(em is expected to allow 
^t^Tc^ns^auScaUy uploaded when the online system is 
available. 

6.3.1.64. The system shall provide a printed report of backup transactions for error 
correction purposes. 

63.1.65. The system is expected to allow and circulation 

rairKtsissK — ■*- - — 

of materials 

6.3.1.66. The system shall aBow tibr^K^ 
multiple locations and for multiple parts of the horary 
portable barcode scanners. 

63.1.67. The system shall provide reports that wiU assist in returning materials to 
their proper locations. 

6.3.1.68. The system is expected to ^^dSStion unit, and, where 

6 3 1 69 When an item is removed from the database, *e option to retain its 
hareacticmhistory and statistics is expected to be available. 

6.3.1.70. The system is expected to provide *e option for libraries to maintam 
circulation statistics for all issues of serial titles. 

63.1.71. The system is expected to provide the capability of listing holds placed for 
on-shelf items by library. 

6.3.2 Name/Address parent institutions are moving 

63.2.1. Participating librar ie s^^ong with IP wiU be stored in one place within 

towards a data model where database with SQL access or an X.500 
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£* " Paren * inS ® Uti0n ' 80 *» wm “^ue to be 



?^rf 1 !u abOVe ^ n y irQ ^ ment may not be fully in place before the new system is 
Astern. remammg ltems address a desired stand-alone user file in adulation 

hf^i' At 3 m ? li f lmn/ t thfi s y stem is expected to make it possible to retrieve 

rprfr^c T he , system 18 expected to have the capability of creating name/address 
and human ° rrowers from machine readable information obtained from student 

***(? X50 ° ***** databases * Whethe"4e 

£Si^ d ^ - 

ame/address records should include a field for e-mail addresses, 
records *»** “* edi ‘ — ^dress 

update *° emplo >’ some method, such as date of last address 

X 8 *!' 5* contr °‘ whether incoming machine-readable borrower information 

of ovmlltfo?^T^for t ‘ OI> f m U ’ e borrower file h> order to minimize the possibility 
or overlaying old information over newer information in the file. V ’ 

?: 3 ' 2 ' 8 -. U . record ,f ^eted- then the system is expected to also delete any 

SsS^^r^^ssst: - - 
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imd to charge items using proxy borrower ID numbers. 

, ,,10 The system is expected to have the capability of assigning tire same 
*Sg£ 2K£SK*S tvtg^Uin^uItiple borrower 
records for the same person. 

which is the borrower s preferred method and addres S 

6.3.2.12. The system is expected to have at least two fields which can be customized 
and are available for local data or flags. 

63.2.13. The system is expertedtomake toddle 

message in a borrower record. It shall P , .. .»| Hicniav during any 

whether or not this free text will ^^ e ^^ r ^J^h e ther it will be automatically 

at the next transaction or at a time determine by 

the staff person. 



63.3. User Accounts for Circulation, Reserves, and Interlibrary Loan/Document 

institutions ID card debit strip) and print a receipt. 

descriptions.] 

loan and document delivery. 

6 3 3 5 The svstem is expected to allow authorized staff to edit borrower account 
mcords^dSg cleaSg charges, consistent with audit trail requirements. 
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6.3.3.6. The system is expected to allow payments to be posted immediately after fees 
are added to a borrower’s account and to dear restrictions on the patron's activities. 

6.3.3.7. The system is expected to allow fees to be posted to particular income 
accounts. 



6.3.3 .8. The system is expected to maintain an audit trail that conforms to generally 
accepted accounting prmdples for all finandal charges levied against a borrower 
mduding a complete history of debits and credits or payments. 

6.3.3.9. The system is expected to have the capability to display debits, credits, and 
payments by die circulation unit at which the original debit was incurred. 



6.3.3.10. The system is expected to make it possible to display and print only the 
unpaid charges for a borrower. It should be possible for either a staff person or the 
user, with appropriate authorization, to request this information. 



6.3.3.11. The system is expected to display and print on demand a statement of 
account, mduding credits, for a user. It should be possible for either a staff person or 
the user, with appropriate authorization, to request this information. The user 

i » eqpceteci to provide a reminder to the user to sign out once all requests 



6.3.3.12. 

notices. 



The system is expected to print a borrower’s account balance on account 




6.3.3.13. The system is expected to allow an individual library to process full or 
partial payment of any account at any time and is expected to adjust the borrower's 
account balance appropriately. The system is expected to allow the circulation unit 
at its discretion to post partial payments to appropriate charges in the account 

6.3.3.14. The system is expected to alert staff to follow up on adjusted accounts at a 



6.3.3.15. The system is expected to make it possible to age accounts and to produce a 
report of outstanding fees based on amount owed and date fees were charged. 

6.33.16. Tlie system is expected to produce a report identifying items that are 
significantly overdue to alert staff for possible billing of replacement costs. 

6.3.3.17. The system is expected to allow participating libraries to establish different 
bilbng periods and charges and services fees for different types of materials, for 
different circulation units, and for different user categories 
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JSt. R TwTvstem is expected to provide functions with which a staff person can 
tsUy in^teSan uL has bin relocated to a reserve room or locahon. 

63 . 4 . 2 . The system is expected to place items on reserve that are not represented in 
die catalog database. 

6.3.4.3. the system is expected to assign a unique shelving number to uncata og 
items that are placed on reserve. 

ssi 

when the item is not on reserve, 
command or procedure. 

6 3 4 6 All displays that include location information for an item are e?cp^:ed t° 
item. 

interface is expected to provide a reminder to the user tosgn 
requests are placed. 

course aSTpTfes^ 
limit. 

6 . 3 . 4 . 9 . The system is expected to make it possible to delete all items on a reserve kst 
with a single transaction. 

6.3.4.10. The system is expected to process with a single (transaction a chang 
related to the reserve function for all items on a reserve lis . 

s^rswssrsft ssssssassr 

access points. 

5i 
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6.3.4.13. The system is expected to allow an item to be placed on reserve for more 
than one academic course and/or for more than one faculty member 

6.3.4.14. The system is expected to allow different loan periods for different coDies 

wforr p ttn fo reSte CW ' 0ai> *" ^ 

* aa sss jess ss^jsszzr 

fmovtd tamTe^e. eXP “ ted to a staff P ere °* ** « - due to be 

reserve* f^Hon^ * *° " P° Ssible to «H fields related to the 

6.3.4.18. The system is expected to gather information within the reserve function 
on charges, renewals, discharges, and in-house use, by location, by circulation unit 

materials* P ° SSlble ' by borrower type for statistical reports of various uses of 

The 7 StQm I s ex ?f cted to calculate overdue fines on an hourly basis and to 
produce overdue notices for reserve items. y 

6.3.4.20. The system is expected to retain bills and accounting information associated 
with reserve items even after the item is removed from reserve. 

6.3.4.21. The system is expected to provide links from the traditional reserve svstem 
to items available in electronic form, either locally-scanned or available Tom * 

dateh*?' and f u lther ,° n ** Web (or accessor technology), via ASCII or image 
databases on this system, or available via gateways to other systems. 8 

6.3.5. Reports and Notices 

fff-J*. 1116 sy8tem 18 ^Pected to generate and produce various batch processes 
including overdue notices, recall and hold fulfillment notices, hold cancellation 
obces, recall notices, recall cancellation notices, fine notices and bills and 
statements of account Notices, bills and statements of account should' be 

sent V ! a e '™ ail or voice-mail to the borrower's preferred 

fnr^!rh /P /T e nuXI ^ er ' C ? culation «*»■ should be able to customize the message 
for each of these notices and to print it at the circulation desk if desired. 8 

63.5.2. For all notices produced in a batch mode. The system is expected to allow an 
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notices sent on demand, 
been placed on a charged item. 

6 354 Circulation units associated with one administrative unit are expected to be 
control the sequence and scheduling of circulation nobce and report 

production. 

, * e e xhP svstem is expected to allow use of electronic mail or the telephone for 
receiving notices. 

6.3.S.6. The system is expected to associate a borrower record be 

statistical categories for statistical reporting purposes. These categone 
definable at either the system or local library level. 

636 1 P cStion functions are expected to be controlled by a Ub^drculation 
^t-SDedticset of^ tables that can be maintained by an authored staff person 
withouTtihe assistance of the vendor or system management personnel. 

63.6.2. The system is expected to allow a Ubr XtT^ff^?ci^gSTofdSferent 
different sets of parameters govenung the pnvileges and lines cnargea ror 

categories of borrowers. 

owed, or number of items overdue is reached. 

63.6.4. The system is expectedtosu^rtal^ei^berof 

Describe how the system would handle borrower categories & 

libraries and circulation units. 

6 3 6 5 The system is expected to define a default loan period for each location and 
overrideor dhange the loan period either at the item or title level. 

6 3 71 ’’Ste'svstem is expected to inventory the collection and/or selected portions 
SKJWWK to establish a beginning and end date to an mventory 
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period diiring which any item charged or scanned through a portable device is 

th f period a Ust shouId be produced of all items not charged 

Sjztsr sar* ■>— *■*«"» «<» — £*■ 

Md/or'k^adoa” ** eXpeCted to P rovide a re P° rt of “issing items by holding library 

63.8. Interlibrary Loan (ILL) and Document Delivery 

6.3.8. L The system is expected to support user initiated resource sharing 
transactions, including local loans, interlibrary loan, and document delivery. The 

mqueTte^epla S ced PeCted t0 prOVide a reminder to the user to sign out onceall 
638.2 The system is expected to support interlibrary loan and resource sharing 

prot V «<S mOT°/mVi ySlemS that comply with * he 130 Intcrlibrar y *«“ •*■«««» 

iw; 3 <J^ SySt T is ^ p !^ ted to Provide for user-initiated interlibrary loan for 
,.v OU ? d m 239,50 compatible catalogs, but not in the participating library's 

efnnr^r^f^ t£> desi g^ ated e *temal interlibrary loanfyste^ 
•gv OCLC, RLG, MINITEX, DOCLINE, CIC institutions, etc. 

Specify the automated interlibrary loan systems to which your system 
currently mterfaces and the manner in which it does so, including any 
standards employed and authentication processes. 

Specify your system's capabilities for facilitating ILL transactions with libraries 
not on an automated system or with systems that do not comply with the ISO 
Interlibrary Loan protocols. 

Specify your system's capabilities for handling requests from unaffiliated 
users, who have previously set up accounts with the participating libraries, 
for fee-based document delivery. ° 

Specify your system's capabilities for interacting with participating libraries 
purchased accounting system for its income operations. [See Appendix E for 
descriptions and vendors.] “ 

6 ' 3 ' 8 ’ 4 ' 1 ? ,e system is expected to have the capability to accept user-initiated loan 
requests from both public and remote-access workstations including via the Web. 

63.8.S. The system is expected to have the capability to interact with the circulation 
y em in blocking requests from patrons who have exceeded certain limits, such as 
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number of items charged out, amount of money owed, or number of items overdue, 
or have other restrictions on their record. 

6.3.S.6. The system is expected to have the capability to accept multiple staff-initiated 
interlibrary loan requests on behalf of a user. 

63.8.7. The system is expected to assign a record number and date and time to each 
ILL request when entered. 

6.3.8.S. the system is expected to P^^Twor^ 

activity requests at pub of a 

reminder to the user to sign out once all requests are placed. 

63.8.9. The system is expected to provide query access by authorized staff to 

interlibrary loan requests by: 

Bibliographic field 
OCLC numbers 
NLM numbers 

RLIN numbers Hhrarv 

MIN1TEX request numbers, as assigned by y 

User ID 

UrdqueTruunbers (su ch as hacking numbers assigned by the library) 

6.3.8.10. The system is expected to of returnable items, 

ILL requests. Once the request has been fflMmd, m the ' case iot afBIiation , 

returned, the borrower infonnahon s^idd only or Ubrary- 

and interlibrary loan office han S ^ b archived off-line but remain 
specified period, this information is expected to be arcraveu o 

accessible for query and reporting. 

^ar^v^ 

will support. 

6.3.8.12. The system is expected to permit the archive to be queried by: 
Department/ major of use 
User type 

Periodical /item title 
Unique number 
Item author 
Lending institution 
Borrowing institution 
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• MINITEX request number 

Specify how the system protects the privacy and security of this function. 

6.3.8.13. The system is expected to have the capability to integrate / when 
appropriate, interlibrary loan or other fees into the patron s fine account. 

6.3.8.14. Billings that are issued to the user are expected to include interlibrary loan 
fees, which contribute to calculation of a fiscal-based restriction on a user. 

6.3.8.15. The system is expected to interface the ILL subsystem with the 
circulation system activity to create interlibrary loan reports. 

6.3.8.16. The system is expected to allow online or printed reports by category of ILL: 
complete, received, returned, will supply, shipped, unfilled, etc. 

6.3.8.17. The system is expected to provide access to titles that have exceeded 
copyright limits. 

63.8.18. The system is expected to support ILL participation by non-system libraries. 

These subscription ILL members shall have all the same ILL capabilities as the full 
participants. 

6,3 ; 8 J K 9 T L T I?f system is expected to accommodate ILL participation with centers such 
as MeNITEX Describe how the system would handle copyright compliance in this 
environment. r 



6.3.8.20. The system is expected to provide an unmediated environment for 
handling user-initiated requests. The system is expected to provide libraries with 
the option to have the system automatically reject requests under conditions 
specified by local libraries. The unmeditated feature is expected to provide libraries 
with the option of creating profiles of potential lending libraries, in priority order, to 
which request records are routed automatically. 



6.3.9. Borrowing (ILL) and Lending Requirements 

63.9.1. The system is expected to support requests for a physical items, requests for 
document photocopies, and requests for materials in electronic format. 

• Additional information (volume, number, page, article author, title, etc) as 
well as user notes is expected to be allowed in the request. 

Items requested may be local (local loan between circulation units), remote to 
other borrowing institutions (interlibrary loan) , or external through a vendor 
document fulfillment service (document delivery). 

• The system is expected to allow for multiple delivery options of the requested 
material, including but not limited to e-mail (with or without MIME), fax. 
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FTP UPS standard mail. Each library administrative unit is expected to have 
the option of specifying which delivery options will be supported, based on 

local availability and policy. 

• Requests MAY be in EDI or EDIFACT format 

63 . 9 . 2 . The system is expected to be able to collect the bibliographic information for 

catalog (for local loan requests); 

. The results of a search of a local index and abstract or full text database (for 

local loan; document delivery, or interlibrary loan); ff 

• The results of a search of one or more external catalogs or databases (for local 

loan, interlibrary loan or document delivery); . , . . 

• The request interface is expected to provide the °pti°nfor blank r ^est 
templates that can be used to request items/documents that have not been 
located in one of the local or remote catalogs or databases. 

ft 3 9 3 Document requests are expected to seamlessly interface with the online 
“tatog seSfsyX and are^cpected to support the ability to search mulbple 
remote Z39.50 catalogs and databases simultaneously. 

. •^ document request function is expected to be fully ttte 

search functions; i.e., users should not be required to enter a docum 
rpmipct module to search for items to be requested. 

• The document request command is expected to be readily apparent to users, 

. ifth^tem^edfied 3 by^multiple institution search is requested, all of the 

the request will be recorded 

. Locally held items would should be dynamically identified for the u^y the 
system. If the item is locally held, locally specified rules, 
status should determine whether an external request shall be allowed. 

63.9.4. The system is expected to capture and/or import the 

remote or local catalog or database using NISO standard Z39.63 or from u p , 
as appropriate: 

• Bibliographic/citation information; 

• Location, call number, shelf status (for catalog items); 

• Date item no longer needed. 

6.3.9.5. The system is expected to allow staff to add verification information to a 
request record. 

6 .3.9.6. Document requests are expected to interoperate with OCLC, and should 

^"cSh^v^STexpected to have die option of allowing users to 
search the OCLC, RUN Z39.50, and DOCUNE servers 
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• be ab,e to place ■» “• -*-* ™ ^c, 
run^ dwxd^iS^s^. *° te able to receive requests £rom 

Describe how this interoperability is achieved. 

fuftia^eZ^r 5 * faterfa “ iS expected *° CoUeCt user “d 

• “ 1 expe u cted to P rovide ^ option of requiring users to validate 
against the local authentication source. The source may be internal such as a 

• ^ tei * user file, or external such as an institutional X.500 directory/ 

^o^Whf a , uthenticated ' ** s y stem expected to verify the user's 
authorization to place a request (e.g., the user is not blocked by 

t^gcry, etc.); criteria for authorization 

• _e expected to be flexible based on the administrative unit's policies. 

mte f fac ® 13 expected to provide an option specifying how many 
requests can be placed and how much time is allowed in thesame session 
before a user is required to re-authenticate. The user is expected to be able to 

• Thp 6 mulh P le f re q uest s without having to re-authenticate P each request 

The user interface is expected to provide a reminder to the user to sign out 
once all requests are placed. me user to sign out 

• 40 ** Iocal authentication server are expected to use 

cachPth d standards and/or interfaces. The system is expected tobe able to 
cache the user information to eliminate reauthentication. 

iS eX K Cted to ca P ture and/or import the following data from a 
local cumulation or user ID system, or from user input, as appropriate? 

• User data (name, ID number, etc.) P 

.• (deUvery address ' fax number ' e-mail address, etc) 

formation (account number, credit card information, as 
appropriate). 

6.3.9.9. The user is expected to have the option to cancel a request prior to sending it. 

adm f i l strativ e unit is expected to have the option of allowing users to 
earch their local catalog or databases and place a local loan delivery reauest* that is 

*2555;“ *T b l ddivercd from a local 

. ^ ed * Photocopy. This request is expected to be identifiable by the 

system as needing to be processed by local staff. ^ 

6.3.9.11 The request interface is expected to provide the option of allowing the user 

^ that might be: to his or her d^top; tf^pl^rST 

local ILL office; or to other user-specified pickup location. F PP P 




^ Q 
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The interface is expected to accommodate 

vs^ttssxnsasssG? 

suppliers or on-campus/iibrary document suppliers that charge a fe . 

6.3.9.13. The system is expected to support electronic commerce in a netw 

. a^a^isTx^Kow the institution to charge tire user for 

. ^^rre^^^Wuser.esti.headdedhy 

. ^“.Sarged, a variety of Pa^^^f 

depending upon the document supplier and the policies of 

administrative unit. 

63.9.14. The interface is expected to protdde “ ‘ * 
has been successfully P la « d n 3“ ^em^ bStiSr^Wc information, date/time 

a verification/reminder of the request. 

63.9.15. The system is expected to provide ^capability rte £ *" 

his/her own outstanding request; the request to se^chs ^ ^ 

authenticating the user. The system is expected PP^. The user interface is 
status of the request based upon the status ™\^has finished 

expected to provide a reminder to the user to sign out once ne or sne 

searching. 

63.9.16. Requests from the user request Werfece ^^note Srera^Si^ 

appropriate Z39.63/Z39.70 elements and be able to be ram 

the Z3950 Extended Services Document request/ILL protocol as propo y 

National Library of Canada. 

63.9.17. The system shall allow multiple^ P 0 *^ °^ a “^““^Jtt^tic 

shaU automatically forward the request from one lmd« toi toe next, 
forwarding shall occur after a library-speafied number of days. 
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libraries' circ^atio^sy^m! ^ ifem mes 0t C^ l ? ndkx 8 and borrowing 

recalling ILL items shall uDdate th* i i tem files, J renewing and 

notices, overdue'rwtices “ weU - ^L availability 

the circulation records. ' ' ’ * uB be able *° b ® Senerated using user data from 

no 3 ; 9 sippS l d. SyStem * eXPeCted *° SUpp0rt * e *“% «» "Vitiate requests that were 

^ 9 i«^l& t ^ , S^ to JSl de a meSSagin8 feature *° b <~g 

This Shan iuowfa! ?“ , mes *>S es «« ILL request record, 

messages via the status trfckin| file ^ forth with noUfi aaaon of pending 

active ILI^panidpante. *° bl0Ck re « ues * s to “s *at are not currently 

?*?*?!*i JI i Staff Management Requirements 

link the two transaction!™ ” locaU > r assigned number in order to 

ejected ES tfroftte'tf ?? ^ “ d back «• «quest are 
was requested, torn w hl §/Chlffin^? UeS |I transactlon ' showing when flie item 



destination: ““** rf * *****'’ ““ s ^ tem «• expected to choose a request 
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. issxsssir’ 

system If the holding libraries have been 

non-media ted requests. The request is expected 

holding library system via Z39.63 over TCP or using Z39.50 Extended 

. Otherwise the system is expected to allow staff to ‘dent'fy a Riding 
library via Z39.50 or other searching functions, if needed, at whi 
pointthe request is forwarded to the destination or the request is 

rejected per local policy. 

6.3.10.5 The system is expected to ^eSSS'p'^ 

download in batch pendmg requests; to sort toe PP m* Jy 

that include bibliographic formation, local call number, au tenaing uoroxy 

addition to especially flagged requests. 

6.3.10.6. The system is expected . o ^m.^status^alu^ » tmnsacB«». *1, 

status is expected to change as identified in Z39.63 and me ^ ^P 
values, the system is expected to set status values automat • y based on 

processing, on individual items during staff review, or m a batA update based on 
Lstitution specific criteria, such as status, date in queue, institution, . 

6.3.10.7. When the requester’s item arrives fiie system ^P^^noti^g^at the 
status change in the system and a notice that is sent to tne reque ^ 

item hib2n received and where it can be ijdcedg- 13 ex P ec 

support paper, telephone and e-mail request notification options. 

6.3.10.8. The staff management interface is cxpecte dtoallow ori ginating 

transactions by a variety of criteria, including but not bjmtedtouser ID, origma g 
institution, transaction status, system assigned transaction identifier, 

number. 

6 3 10 9 The staff management interface is expected to allow purging of completed 
tt^aLm by a v^t/of criteria, including date and item type. Automate 
p^tVbSed y on spectoed criteria is expected to be a locally speofied ophon. 

63.10.10. The ILL system is expected to maintain s ^“ cs “"^^^“Sed on 
interlibrary loan work forms to move from any .?P*?^ S,„"pending" to 

local library or consortium selection, eg. pending PP / 




61 



50 



oS!t; d r^ period 

SSX- h0d ** «■ - « and 

journal title and artide dtation^ of^S^^ re P ort Iistin g the 

suppliers. *** non retuma ble items requested from 6 

6.3.10.13. Describe how the system: 

• ~ 0n j!° rs C0 Pynght compliance 

Handles requests which would violate copyright compliance 

copyright compfiance. automatica % block a request when it would violate 

Kfola^r ^ ^ ^ ** KL ™ P— *0 override blocks for copyright 

information. ILLtoff d»S be°abk a “ e “ to co Pyright compliance 
information is expectedtote seci^e soS o* * fol their Ubrar >’- The 

not available. e 80 * at other bbranes' copyright information is 

any toe btore y ^l'plS ll0 ' V **“ *° ” ake Changes *° HX request record at 

*« -me item even if 

number from each 

y viae tnis mformahon m successive requests. 

6.3.11 Compact Storage 

by ato^raries^^^ a ri^state^vvMcii e wi n* 8 ^ St0ra 8 e faciUty ' available for use 
Shelves. As we move iW to '«? ESte to! ZT “• M btas rather « han °» 
h;ansfer of the item to a new location^ / tem ls ^Pecfced to support the 

bins, facilitate the paging of these items manaf D J? 1 . age . the stora S e of the items in 
status of the item to the user of the online catdoa^R* <nrcuJation ' display the 

access to this faciUty, not all of their r^ds wm hi ^ many Iibraries have 
database. Please describe how the sy^wodd s^Sa ^s” 
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6 4. Database Maintenance and Cataloging 

This section describes system capabilities that have to do with the creahon and 
mainten ance of bibliographic, authority and holdings records, the records that 
comprise die catalog database. The system shall maintain each bbraiy's 
individualized bibliographic data. Each respondent is expected to desmbeindc^ 
the manner in which its system functions with respect to each desirable capability 
described below. Local libraries and consortia shall be allowed to describe how they 
wish t hei r records to be handled and displayed. 

[This section may need revision after decisions are made about the relationships and 
decision-making processes among participating libraries.] 

6 411 The system is expected to allow libraries to transfer batches of bibliographic 
oSSs orindividual records from national biblio f aphic utilities or 
vendors to a server using file transfer protocol CFTP). It sbovldbe ^“fto 
convert, index, and load these records into the OPAC m a single transaction. 

6412. The system is expected to make it possible to (1) search for individual records 
or small fitef of records on any Z39.50-compliant server, (2) mark “ c ° rds <*) “ ** 
result set for import, and (3) ckpture, convert, index, and load marked records into 

the OPAC in a single transaction. 

6.4.1.3. The system is expected to make it possible to create a new record by deriving 
from (copying) records in the local file/s (e.g., OPAC, locally mounted resource file 

of Library of Congress records). 

6.4.1.4. The system is expected to make it possible to key brief ' 

online with a minimum number of keystrokes and point and click operations. 

6.4.1.5. When a new bibliographic record is added to the system throu^ import or 
derived, the system is expected to create a default holdings record as well as a 
bibliographic record, the system is expected to include the following data m the 

hoidingsrecord-xhe location is expected to be tables-driven ^dU^fidto 

operator ID, but the system is expected to provide the option to set anoth 
default location during work session. 

. Call number: Call number data is expected to be copied from fields ^edfiedin 
priority order in a table. The system is expected to make it possible to specify 
priority orders and link one order to an operator ID. The system is expected to 
provide the option to set another default order during a work session. 
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number of characters allowed for a single record 
(bibliographic, authority, or holding) is expected to exceed 20,000. 

1 ^\^ axin } um number of indexed fields allowed for a single record 
(bibliographic, authonty, or holding) is expected to exceed 500 fields. 

w^t hS^s ^,rf eXPeeted ‘° aSSOdate m UnUmlted ™“»ber ttem records 

f* 4 * 1 *?* iy^ en bib li°gmphic and authority records are imported from databases 
system ' ** system is expected to automatically overlay an existXg 
XlutfwT 6 *5“? With a ”***** standard number; the Lite 

andlt^oid^be^w^i ^/*^ 4 ^^ 111 ^ 11 ^ 618 316 to be med 38 basfetf o^l^ 

staf f person to change the definitions 7 

6.4.1.10. If a new bibliographic or authority record entering the svstem from a «„ 
source and by any means (a) contains a control number that duplicates a number 
^ ym the cataIo S database or (b) using an algorithm based on indexed fields 

the^Stio^?fh^ eady Cata2 ° S database ' the system is expected to prevent 

worW fiT 1 T T Td to * 6 , Catal ° g database end store the incoming rlZrTL a 

workmg file so it can be examined by an authorized staff person. 

6.4.1.11. The system is expected to accept support, and maintain storage retrieval 
JgSSSC 8 Cti0nS ““ CapabUitieS fOT « enre *»bject headings and local 

ro!ii 2 ‘ S 16 SyS f em is expend to transfer and overlay online a single bibliograr»hic 
record with another record -either with a record from the same ^ P 

the existing record or a record from another file such as a resource file of Librarv of 

aU,0maKCally replaCe 3 **"« bibliographic 

ordcrrec^dS' 1 ' “ ‘° prevent over,a y from affecting circulation or 



VH SyS ,‘f m f xpected to allow local Ubraries to define which linked 
%££*£££* by OWrlay - ** bibli °<« “«>«■* <*ly or Mb^phic 

fidt whe^™^;^^.^ l0Ca ' HtrarieS «* “™“* *° 
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6.4.1.16. The system is expected to mark errors in records imported into the system 
and provide a mechanism for retrieval of error records for correction. Please 
explain how this is handled. 



6.4.2. Record Editing and Maintenance 

6 421. The system is expected to allow a staff person to search for and p y . 
records from any system file at any time during the process f ““togormodjf^tg 
a bibliographic, authority, or holdings record online without having to terminate 
the record creation/ modification activity. 



6.4.2.2. The system is expected to support editing features similar tojhose £ 
commonly used word processing programs (e.g v copy and cut and paste between 
records and insert data at any point in the record). 

6.4.2.3. The system is expected to incorporate data from any existing bibUograpWc or 
authority record into a new record that is being online or into an existing record 

is being modified online. 

6.4.2.4. Each staff person at a participating library who perfo^ onlinecreationof 
bibliographic, authority, and holdings records is expected to be able to define and 
have the system display easily defined default values for certain tags, indicators, and 

subfield codes. 



6.4.2.5. The staff person is expected to be able to control the order of display of 
subject fields, added entries and notes fields by arranging the order of the fields in 
the bibliographic record; the system is expected to preserve the order when the 

record is stored. 



6.4.2.6. The system is expected to validate the following data against a master ta e 
whenever a record is created or updated: 

• All values in 006, 007, and 008 fields 

• All field tags 

• All subfield codes within each field 

• Repeatability of fields and all subfields with fields. 

6.4.2.7. The system is expected to return appropriate error messages to aid in 
correction. 

6.4.2.8:ihe system is expected to do record purges by parameters (date, etc) specified 
by an authorized staff person. 

6.4.2.9. It shall be possible to immediately delete or undelete bibliographic records 
from an individual library. 
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record that haT^y j r^wds^slda ted with h* ? advertent deIetion of a bibliographic 
option should be provided XTfsta^^L ™ SSage ' P 10 ^ override 
record with other Lodated^eSrds ^ attemptS to deIete a bibliographic 

item reflected hi thT hold^ ° fa boj^gs record if any 

transaction (bill, hold, recall). ulatrng or associated with a circulation 

^r^^ e ^r^ Uograp f ,ic ' w« holdings 

staff person can review the records before th^ 2£3&£ ^S^TSSStaS 
hbrar^'to^th^ 6 P ° SS “ ,le *° C ° Py 3 **• “hUographic MARC record from one 

daw£k The SyStem b expected to '“h’hdn a history of edits for each library's 

6.4.2.15. It shall be possible to edit and produce labels, both single and multiples. 

6*4.3. Authority Control 

authority record for a subordinate y related headings (e.g., recognizing an 

of the higher body's name in the ectehr If conflict if it uses an obsolete form 

reported 8 Ihe sy74T«p^£ • bo should be “^ed and 
y 15 expected to ldentlf y blind references and notify the user. 

**** * Staff "> d ^ public references 
bibliographic fifoX examcIp 'W.^ . ° n r ?" ds not mate *«d in the 
hierarchy or sequence of related heading- ** r8COrds needed to complete a 

expected 10 make 8 ,0bal ^8- h> bibliographic, holdings and 
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a text string to records based on the presence of other specified data in the 
records or delete a specified text string from records. 

• an authorized staff person can control file global change process so that only 
occurrences in a specified field and/ or subfield or fixed field data position are 
changed. 

• an authorized staff person can control the global change process so that 
heading elements may be rearranged based on subfield code alone, in 
conjunction with a partial heading text, i.e., use the global change process to 
reorder spe cifi ed topical subdivisions in relation to variable geographic 
subdivisions when the former change from "Not Subd Geog" to May Subd 
Geog.” 

6.4.3.5 The system is expected to make it possible to review the consequences of a 
global change to the database before it is implemented. 

6.4.3.6. The system is expected to alert file staff person when a heading in a 
bibliographic record (lxx, 4xx, 6xx, 7xx, 8xx fields) that has been created online or a 
heading that has been added to a bibliographic record that is being modified online 
does not match an existing record in the authority file. 

6.4.3.7. The system is expected to be able to replace existing authority records with 
newer versions loaded through either batch or online process, and is expected to. 
provide the option of automatic replacement of headings in affected bibliographic 
records. 

6.4.3.8. System generated authority records for unmatched bibliographic headings are 
expected to include 670s when identifying data from the 245 and 260 fields of the 
source record. The system also is expected to supply rule-based 4xxs (e.g., rotation of 
multiple surname headings within the heading and lxx/245-based references for 
records generated from lxx /240 headings). System-generated authority records 
should be created both during batch record loading and during online cataloging and 
record maintenance. 

6.4.3.9. The system is expected to report the entry of new controlled headings into 
the indexes, regardless of the source of the heading, and report duplicate headings 
and authority heading/reference conflicts resulting from the addition of authority 
records to the file 

6.4.4. Holdings 

6.4.4.1. Describe how the system structures holdings data. 

6.4.4.2. The system is expected to place no limit on the holdings data that can be 
associated with a single bibliographic record. 
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to perform 

£3 of holdin8S JSSS^ hSSgJ 




* to del ! te , a I elect ® d ^"P of holdings records 

to control Uie order of holdings display bv location 

* customize messages associated 

records with , 

monographic series. mmodate bound-together items and analyzed 

£»£ ff 8 * ?“ a h ° ldin « s «°» d *• location of an item 

reference ur4. l0Ca,ed * “* ** « * the 

informal for ^spwffif rom? andtfmJbf > ° rIZe<1 *?®i 0 su Ppress the holdings 
record in the OPAC PX * ^ preven » tt,e ^Pty of that holdingf 

6.5. Acquisitions 

^ip^Tbmy^te^X^r that to d ° ** *e ordering and 

activities. Each respondent is expected to teafte in detil*^ 1 * 1 ** accom P an )' such 
system functions with resDect fn iL„k • ui i 11 ^h e manner in which its 

respondent is ^oexp^tedto^eMrib^n”^ ^P^mty described below. Each 
example, fund nus,K nltl^qu 2 Lt ^ (f ° r 

6.5.1. Integration 

record frwn display ^th^OPAC ^ " aUth0ri “ d Staff P*«°" *o suppress a 
■performing acquismons^dfoj^ <3ispiay records hoot any system file while 
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6.5.1.4. The system is expected to allow an authorized staff person to suppress 
specific fields in a record from display in the OPAC. 

6.5.1.5. The system is expected to provide a hot link to a UKL from the OPAC if the 
record has information in the 856 field. 

6.5.1.6. The system is expected to be fully integrated with document delivery 
functions to allow for acquiring, tracking and paying for journal articles and other 

individual pieces. 

6.5.2. Ordering . . „ 

6,5 2.1. The parameters that control how the system carries out various acquisitions 

operations are expected to be easily modified by an authorized staff person without 
the intervention of the vendor or system management personnel. 

6.5.12. The system is expected to place no limits on the number of order records that 
can be associated with a single bibliographic record. The system is expected to allow 
the library to specify the data elements that appear on purchase orders, whether 
printed or electronically transmitted, within the parameters of EDI and other 
approved standards. Describe how the system produces purchase orders. 

6.5.2.3. The system is expected to make it possible to correct or cancel a purchase 

order before printing or transmitting electronically. 

6.5.2.4. The system is expected to make it possible to print purchase orders locally, 
possible at the desktop. 

6.5.2 .5. The system is expected to use standard codes for countries and currencies. 

6.5.2.6. The system is expected to make it possible to locally select which fields of the 
order record will be indexed. 

6.5.2.7. The system is expected to make it possible to search and retrieve sequential 
record ID numbers. 

6.5.2.8. The system is expected to make it possible to retrieve payment or check-in 
information for a specific issue within a series or subseries. 

6.5.2.9. Order, vendor, and check-in records are expected to include library-defined 
fields. 

6.5.2.10. The system is expected to provide flexibility in the number and length of 

( fields and include the capability to enter free text notes in variable length fields 

for various pre-defined functions, i.e. ordering, receiving, cataloging etc 




prepaid, renewal™ dlfpoStoryTteml 11 ’ 811 ' *“ itemS n0t received “dess they are 

SS XGSttTSSSr « ^ 

formal ^ to accomodate the following types of orders in any 

Firm orders 
Approval plans 
Standing orders 
Blanket orders 
Continuations 
Serial orders 
Collective orders 
Gifts 

Gratis orders 
Exchange receipts 
Prepaid orders 
Deposit account orders 
Memberships 



And have the flexibility to handle other types. 



default values ^cc^i^^tovendor^vpe taSS^Tn* 3 f ** P erson to establish 

in the order record to bf used by the^stem^hpni^' 01 ° Ca I tion for data elements 
created online. ^ e system whenever an order record is being 

who is creating 0^^ ove^^H ^^ 6 ** authorized staff person 

data elements in the order record on a recordh * s x ste “' su pplied default values for 
default vaiues that are -X **« - 

errors fo^^ed^nrae^Sta^Iemmte^ 7afd ' ff fa real ame “put 

record when foe order rSrd is befog ^ by ** to « <*** 

selected ^ 10 Sl ° ba ' ChangeS to 



f 



59 




(. 



6.5*2.19. The system is expected to automatically check for fund availability at the 
time an order record is created. 



6.5.2.20. The system is expected to make it possible to view online on request the 

complete payment history for an order record. ^ 

6.5.2.21. The system is expected to make it possible to use information in a 
bibliographic record, MARC format compatible electronic record, °% order . 

from lie entering library or any other library system as source data for subsequent 

order without rekeying. 

6.5.2.22. The system is expected to have the capability, at a library s option, to order 
multiple items on a single purchase order or limit purchase orders to single 

items. 



6.5.2.23. The system is expected to make it possible to suppress an inactive or 
pending order record so that it does not display to the public 

6.5.2.24. The system is expected to make it possible to have different copies of the 
same title charged against different funds. 



6.5.2.25. The system is expected to make it be possible to split a single-copy order 
among multiple funds. 



6.5.2.26. A staff person is expected to be able to easily create an order record without 
producing a purchase order. 



6.5.2.23. The system is expected to make it possible to receive and jj*oc ess 
bibliographic information in machine-readable form, via tape or FTP, and create 

linked payment records. 



6.5.3. Claims and Cancellations 
6.5.3.I. The system is expected to 
claiming. 



allow a local library to implement automatic 



6.53.2. Each library is expected to be able to easily control the length factual text 
for individual claim and cancellation notices, within the parameters of EDI and 
other approved standards. 



6.5.33. The system is expected to have an editable preview of claims, whether 
printed or electronic. 

6 . 5.3 a The system is expected to make it possible to correct or cancel a claim before 
printing or transmitting electronically. 
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medesktop. SyStem iS expected to “"» « P“^Ie to print claim, locally, possibly at 
produce a'r^^only*^ SSS? 'olbX*™ * *° make * P ossib1 ' to 

s^sasri ■ « rfitta-* - * ■ . 

cancellation htetoJJ doXto^c^l^. 08811 ’ 18 40 diSplay 8,6 daim •«* 

t0 make il *> ™ «- Claim interval and 

S orriS d m0dify “ ° VCTride 

6.5.3.11. The system is expected to make it possible to produce a claim manually. 

27 *° make * to issue a claim when only part 

^tfauS^ staff person to 

reassign a selected^-^pSTordeS to7eL P ”n^ r ^ “ authorized staff person to 
6.5.4. Receiving and Paying 

with midtiple^hb^y^catiS^/ 01 muItiple ship to/biU t0 addresses for institutions 

*e 4 tae7 r :S7 18 eXPeCted 10 * P 08 ^ 18 *° edit «• vendor and the fund at 

6.S.4.3. The system is expected to place no limits on the size of invoice records, 
vendor rw^^v^orra^'^’i^e 14 P ,^^ e 4 ° S8arch invoice records b V 

processi^toSflKt1ir^MH^7dl2s eIWr4 ^ eIeC * ronic tovoice 
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6.5.46. The system is expected to make it possible to receive and process invoice 
information in machine-readable form. 

6.5.47. The system is expected to make it possible to track copies returned and the 
reason why. 

6.5.48. The system is expected to make it possible to edit library-selected fields in an 
order record that has a received status. 

6.5.49. The system is expected to make it possible to receive items that have a 
canceled status. 

6.5.4.10. The system is expected to make it possible to record the receipt of part of an 
order. 

6.5.411. The system is expected to make it be possible to record the receipt of items 
with or without an accompanying invoice. 

6.5.4.12. The system is expected to make it possible to pay an invoice without linking 
it to an order record. 

6.5.4.13. The order record is expected to be easily accessed and displayed during the 
processing of an invoice. 

6.5.4.14. The system is expected to make it possible to apply multiple credit memos 
to an invoice or a single credit memo to multiple invoices. 

6.5.4.15. It shall be possible for an item record or piece record for the item to 
automatically be created when an item is received. 

6.5.4.16. It shall be an option for the local library to produce a customized processing 
slip automatically when an item is received. 

6.5.4.17. The system is expected to make it possible to identify separately such extra 
charges as postage, bank charges, surcharges, and rush charges and to allocate these 
extra charges among the items in a flexible way. 

6.5.4.18. The system is expected to make it possible to edit a paid invoice consistent 
with the maintenance of an audit trail. 

6.5.4.19. The system is expected to make it possible to select which fields of an 
invoice record will be indexed. 

6.5.4.20. Invoice records sre expected to include library-defined fields. 
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6.5.5. Fund Accounting 

POSSi ^ le to taterface *• system's financial transactions with other 
finmmml jetton and accounting systems at member libraries. 

management^ co^teol fiKre° ** *** mtegrated with ^ acquisitions and serials 

SyStem “ “ pec,ed to “**™ *o Senerally accepted 

Srts *° m f e “ P° ssible to connect the invoice and fund 

Wx E for descriptiL.S ^“o^T^S^ge & 

gwiLaU^acSpted accounting ^indples'f'or **“'*»“ *° 

on a Drinter 25 t0 make “ P 088 ** to Print the audit trail for a fund 

a printer located in a library or output in electronic format. 

disencumbering of funds and the adjustment of fund 

SyM ™ * “ P *^ 10 "**• “ t"*** “ ■«** lo fund 

6.5.5.9. It shall be possible to add free text notes to fund records. 

^ 5 l 10 ^- lll ! J SySte f l * ex P ected to make it possible to adjust fiscal year beginning 
and ending dates for commitments and expenditures. 7 beginning 

S wm beTSxed. *° ^ “ P0SSiMe “> SdeCt which field8 to 8 fund 

ttiv 2 l 71X6 Sy l tem is ex P ected to make it possible for an authorized staff oerson to 
fmnw encumbrance and expenditure linSts by fund either in ter^ ofaSr 
amount or a percentage of the allocation that can exceed 100 perc^ 

6.5.5.13. Totals for a fund are expected to be calculated for display. 

records. ^ 6re ** 6XpeCted to be no limit on *e number of funds or the size of fund 
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6.5.5.15. The system is expected to make it possible to associate funds to each other 
in a hierarchi cal relationship with multiple levels such that a fund can have 
multiple levels of subfunds. 

6.5.5.16. The system is expected to make it possible for a library easily to customize 
and generate financial reports. 

6.5.5.17. The system is expected to make it possible to designate a fund as active or 
inactive. 

6.5.5.18. The system is expected to convert encumbrances and expenditures 
automatically from foreign currencies into dollars and from dollars into foreign 
currencies based on a currency conversion table that can be easily maintained by an 
authorized staff person without the intervention of the vendor or system 
management personnel. 

6.5.5.19. Hie system is expected to make it possible to carry over funds into a new 
fiscal year automatically. 

6.5.5.20. The system is expected to make it possible to define fiscal years differently 
for different funds. 

6.5.5.21. The system is expected to make it possible to specify by fund different 
carryover or rollover types. 

6.5.5.22. The system is expected to make it possible to produce on demand a report, 
specific to the local library's fiscal year, of funds showing budget, amount 
encumbered, amount expended and free balance. 

6.5.6. Vendor File (this section needs review after decisions about consortia) 

It shall be possible to create a union vendor file, with library or consortia-defined 
fields, to which all libraries using the system would have access. 

It shall be possible for each library to add local information to the union vendor 
record. 

It shall be possible for the library specific data, including locally entered notes in 
a vendor record, to display for the entering library only. 

It shall be able to produce system-wide or individual library vendor performance 
reports i nclu ding average fill time, discount percent, number of orders, number of 
claims plumber of cancels, dollars ordered, dollars paid. 

6.5.6.I. There is expected to be no limit on the number of vendor records. 
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connection! S 7 Please descnbe how *• system would make this 
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aCCOmm ° date ^ both 
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of Orders. expected *° ”** » Possible to control by vendor automatic 
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describe in detail the manner in which its system functions with respect to each 
desirable capability described below. 

6.6.1. Integration 

6.6.1.1. The system’s serials management functions are expected to be fully 
integrated with the acquisitions functions. 

6.6.1.2. The system shall provide for a serial/acquisitions interface for automatic 
renewal and payments of serials. Libraries should have the option to override this 
feature. 

6.6. 1.3. The system is expected to make it possible to specify renewal instructions at 
the copy level. 




6.6.2. Check-In 

6.6.2.1. The system is expected to accommodate all types of serials in all types of 
media/ including but not limited to periodicals/ loose leafs/ government 
publications/ monographic series/ conference proceedings/ legal materials/ technical 
reports/ and electronic files. 

6. 6.2.2. The parameters that control how the system carries out various serials 
management operations are expected to be easily viewed and modified by an 
authorized staff person without the intervention of the vendor or system 
management personnel. 

6. 6.2.3. The system is expected to make it possible to authorize a staff person to check 
in materials only for specified locations. 

6.6.2.4. The system is expected to make it possible to search for and display records 
from any system file while performing serials management operations. 

6.6.2.5. The system is expected to make it possible to create serials records either by 
copying the fields necessary from existing records in the system and by manual 
entry. 

6.6.2.6. The system is expected to make it possible to search and display 
serials/bibliographic records along with summary of holdings display as part of the 
online catalog. 

6.6.2 .7. The system is expected to allow identification of serials for checkin by title/ 
ISSN, vendor ID, fund number/ Bibliographic ID,and other fields. 



6.6.2.8. The system is expected to allow free text notes to be attached to checkin 
records. 
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6.6.2.9. The system is expected to prompt for barcode entry if a copy is to be barcoded 
£ c “ on ' “* • ba«ode if Si item or copy isZt toVZlcdit 

6.6.2.10. The system is expected to interface with circulation so that at checkin time 
an item record is created and stored in the item file within circuktion. 

6.6.2.11. The system is expected to indicate the destination for materials (e e routine 

current periodicals, reference, discard etc). matenais (e.g., routing, 

6.6.2.12. The system is expected to maintain an historical payment file that details 

every payment for a specific serial title. * X 

issues of SET * 6XpeCted t0 maintain cumu lati V e circulation statistics for all 

6.6.2.14. The system shall accommodate multi-year subscriptions. 

6.6.2.15. The system is expected to accommodate various enumeration and 

toiT?* 87 designations, for easy check-in of all frequencies of 

publication, regular and irregular. * 

6.6.2.16. The system is expected to generate a reminder report at a library specified 

time pnor to renewal for all titles that must be ordered direct. ^ ** 

6.6.2.17. The system is expected to accommodate multiple copy serial orders whether 
from one or multiple sources and whether from one or multiple tods 

6.6.2.18. There is expected to be no limit on the number of check-in records that can 
be associated with a single bibliographic record. 

T™ ^stem is expected to employ a predictive algorithm to predict the next 
/ S !u ' , ^ithm is expected to consider not only the defined 

p ttem for the senal but past experience in the receipt of issues for the serial. 

materi^u^lr * *° accommodate all types of supplementary 

• special issues 

• supplements 

• inserts 

• pocket parts 

• replacement pages 

• maps 

• computer diskettes 
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• CD-ROMs 

• multiple-part issues 

• replacement volumes, etc. 

And have the flexibility to handle other types. 

6.6.2.21. The system is expected to make it be possible to establish a system of 
priorities for the handling of the individual copies in a multiple-copy serial order, 
in terms of holdings, updates, routing, etc., or to change the sequence of copies 

displayed. 

6.6 .2.22. The system is expected to make it easy to check in an issue at any time, 

regardless of its predicted arrival date, and to adjust enumeration and chronology a 

the point of 
check-in. 

6.6.2.23. The system is expected to support various automatic routing functions, 

including: . . , 

• production of routing lists at a user-defined point in the serials processing 

• mSSenance of different routing lists for different copies of a multiple-copy 
serial order 

• deletion of a routing list with a single command 

• deletion of a specific name from all routing lists 

• printing of all lists . . , , . 

• printing of routing lists at the location of the workstation used to check in 

issues. 

6.6.2.24. Check-in of an issue is expected to trigger a number of locally optional 

operations, such as: . 

• generation of call number labels and routing slips 

• clearing of the claims queue 

• updating of holdings information and OP AC display 

• recording of statistical information about vendor or publisher performance 

• creation of a claim for skipped issue 

6.6.2.25. The system is expected to have flexible capabilities for managing standing 
orders, such as: 

• multiple orders under a standing order 

• multiple levels of hierarchy 

6.6.2.26. The system is expected to have the ability to associate records of individual 
titles to membership records or other global records. 
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frrtn itei^i SUe ^ old ^® s inforinati on is expected to automatically be collaDsed 

mto item-level holdings, subject to override, when bound volu rafare mceiv^d 

6.6.3. Claiming 

p^ig xpected t0 S 6 " 6 ”* 6 «“»» “ a Predetermined point in 

6 6 ' 3 ' 2 ' The system “ ex P ecled *° su Pl»>rt claiming on a specific serial order recor d. 
ttes 3 ’ “• SyS * em “ expected t0 P rodu “ date “ of variable length, even quite long 

*° C ° n,r01 ^ «**» interval and 

6.63.6 The system is expected to make it possible to produce a claim manually. 

6. 6.3.7. Ihe system is expected to support electronic transmission of claims 

6.6.4. Binding 

6.6.4. 1. The binding system is expected to be fully integrated with the comolete 
automated system, including circulation and serials management. P 

f yst ? m ls expected to make it easy to create and maintain binding 
so* as spine label, color, location, etc.) for a title and to review and 
modify this information prior to the preparation of bindery fon£! 

transfer oHiinding “■** With «“ binder t0 s “PP ort electronic 

6.6.4.4. The system is expected to be capable of determining binding readiness at the 
copy level on the basis of whether the item is bound, the com^esT^Z 
volumes, the receipt of a specified issue, or user-defined time^tervals. 

6.6.4.5. The system is expected to be capable of automatically producing internal 
bm^g p^dcup usts or slips for items that are ready for 

expected to make it possible to review these lists .Line and mod^foem " needed. 

shlnmlni'f eX P eCted *? be possible to charge all individual items in a bindine 
shipment to a circulation status of "at the bindery" with a single transaction 
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6.6.47. The system is expected to maintain serial copy-specific binding patterns or 
profiles. 

6.6.48. The system is expected to provide spine label support for serial and non- 
serial items. 

6.7. Management Information and Reporting 

6.7.1. General Features 

6.7.1.1. The system is expected to provide a wide range of standard reports. 

6.7.12. The system is expected to use an internal customized report generator that 
allows query by example, using Boolean operators and truncation, SQL queries, 
and GUI (graphical user interface) capabilities for easy query construction. 

6.7.13. The system is expected to provide a method for converting existing 
management data, including an annual snapshot of the entire database. Describe 
how die system would do this. 

6.7.1.4 The system is expected to export all data in standard formats for use in 
external report generation systems. 

6.7.13. The system is expected to provide scheduled and on-demand report 
generation without negative impact on system operation. 

6.7.1.6. The system is expected to allow a library staff person (not a programmer) to 
create customized reports on demand. 

6.7.1.7. The system is expected to have the capability to create "what if' scenarios, 
projecting future trends from current data. 

6.7.1.8. It shall be possible to generate reports with information from multiple files. 
6.7.2. Specific Reports 

This section provides examples of specific management information that the system 
is expected to be able to produce, either online or in printed form. It is not an 
exhaustive list. (An extensive list of desired reports is included in Appendix F.) 

6.7.2.1. The system is expected to make it possible to produce on demand a report, 
specific to the local library’s fiscal year, of funds showing budget, amount 
encumbered, amount expended and free balance. 

6.7.22. The system is expected to make it possible to gather data at the whole system 
level as well as by administrative unit and circulation unit and other levels. 
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acti^tie^dirf ^M Sh ? U rf a ? mty to S enerate statistical reports of cataloging 
activities coded into a locally-defined tag in the bib record ^ 6 



,0 produce “ “ rep ° rt - 
prepaid Mder& Stem “ 6Xpected to make U P ossible to produce a report of unfilled 

means ofcX^Srepo^ * P “ *° *"'* ""*» «>“*»““** by 

pynpnHih!^ S u Sten l *® ex P ected to make it possible to project next year's serials 

0X1 °f rent years (or continuation) orders, cancellation or 
renewal instructions, and country-specific inflation factors. 

iS 6XpeCted to provide . formation on serial s and standing orders 
y ategones, e.g. country of origin, language, vendor. 

6.7.2.9. The system, is expected to be able to calculate the average price of 
monographs, using various criteria. 6 v 

‘”5 sy f ,em h expend to provide a method for tracking order fill 

rate for particular types of orders. 6 

6.7.2.11 The system is expected to make it possible to record in-library use of an item 
cSSdationSe ^ ms orcuiation functions, distinguishing between in-library use and 
Z^rTe ^materials™' ” •**“ infonnation for statistical "ports of in- 

6 12 Sy ? tem ex P ected to make it possible to associate a borrower record 

te trjrdealle tatetKaI Ca,eg0ries f ° r rep0rtin8 purp0ses - n »» Agones are to 

fJ Z ' 13 ' TJ 16 system is expected to produce a report of outstanding balances on user 
accounts based on the amount owed and date fees were charged. 

^Un^beT^Ter^rSr *° pr ° du “ a ^inventory list 

fiemswMe *** ab0Ut “ d abIe *° report « - 
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6.7.2.16. The system is expected to be able to provide statistical reports with library 
specific data, especially by user, language and type of material. 

6.7.2.17. The system is expected to interface the ILL subsystem with the circulation 
system activity to create interlibrary loan reports. 

6.7.2.18. The system is expected to allow online or printed reports by status of ILL: 
complete, received, returned, will supply, shipped, unfilled, etc. 

6.7.2.19. The ILL system is expected to maintain statistics on loans requested and loan 
filled, sorted by institution and cross-tabulated. Statistics are also needed on 

the n um ber of inter-campus and inter-library requests. It SHOULD/MUST be 
possible to compile these statistics in any arbitrary date range. 

6.7.2.20. The system is expected to have the capability to maintain statistics on the 
time taken for interlibrary loan work forms to move from any specified status to 
another, based on an individual library selection or a consortial selection, e.g. from 
"pending" to "shipped," from "pending" to "received." 

6.7.2.21. The system is expected to provide a method for tracking ILL fill rate and 
turnaround time for each lending institution. 

6.7.2.22. The system is expected to supply a copyright compliance report listing the 
journal title and article citation of all non-returnable items requested and received 
from non-commercial suppliers. 

6.8. Media Booking Module (needs to be written and reviewed) 

• Intuitive system. 

• Compatible with Circulation subsystem. 

• Ability to select, book and track all pieces of equipment/media at all times. 

• Maintain a tracking history of equipment/ media, e.g. where has this piece of 
equipment been the last several times it was booked. 

• When selecting an item to book, system is expected to have the ability to key 
on specific coded information for each type/category of equipment or media 
title. 

• Equipment data needed for proper identification and inventory of equipment 
are: make, model number, serial number, year purchased, vendor, purchase 
price, bulb type, general notes field (256 character minimum), repair notes 
field (256 characters minimum), preventative maintenance notes field (256 
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character minimum). Searchable field would need to be at a minimum: 
make or manufacturer, model number, and bulb type. 

• The system is expected to allow an item to have repeat booking, e.g. if a piece 
of equipment is used on a regularly scheduled basis by an instructor. 

• pie system is expected to have the ability to accept date, time frame and 
delivery location needed for items. The calendar the system maintains is 
expected to extend for a minimum of 18 months ahead. 

• pie system is expected to have the ability to, if the first item in a category is 
booked, immediately proceed through the list of that equipment/media type 
until it exhausts the supply or finds an available item. 

• pie system is expected to supply all user data into the booking module simply 
by supplying the patron barcode. 

• The system is expected to, when date of booking time arrives, automatically 
check the item out to the patron desiring the item. 

The system is expected to designate date and the system will supply you with 
a schedule of items booked for that day online. 

Ability to generate at any point, in printed form, a schedule of booked items 
indicating who the item is reserved by. If delivery is necessary, it should 
report destination and time, e.g. daily delivery schedule. 

Do not allow bookings of equipment/media from a public terminal. Access to 
media booking module is expected to be password controlled. 

• System is expected to allow staff to override check-out periods as needed. 

7. System Software and Operating System (to be added later) 

8. Hardware (to be expanded later) 

8.1 Workstation Requirements 

For staff in-library clients, a current version of Windows shall be supported. There 

?aYT at , least one P ublic in-library client, which may be either Windows-based or 
Web-based. For public uses originating outside of a library there shall be a fully 
functional Web interface accessible with a standard Web or successor technology 
browser. The system shall support at least one client which can be used in dial- 
access situations and one client that is compatible with standard adaptation products C 
used by individuals covered by the Americans with Disabilities Act In practice, any v 
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of the clients may be used in or out of the participating libraries depending upon 
local choice. 

Given these clients, respondents shall describe minimum hardware requhemente 
and software requirements for the desktop computers to be used as devices for the 

system. 

9. Data Conversion, Delivery, and Installation (to be expanded later) 

19.1 Data Conversion 

9.1.1. The vendor shall convert the following types of records: 

Authority 

Holdings^(including local copy holdings and MARC holdings data) 

Item 

Order/Pay/Receipt 
Fund 
Invoice 
Patron 

Patron Accounting 

9.1.2. The vendor shall maintain the following types of links between and among 
records: 

• Patron to charged item 

• Patron to patron accounting 

• Patron to charged item to patron accounting 

• Invoice to order 

9 1 3. In order to estimate the process and effort required to convert data currently in 
the systems of participating libraries to the new system, the vendor is asked to 

r^p'^Smadon required from the participating libraries in order to 

carry out conversion tasks. . , , , 

• Supply copies of forms typically used to record information needed for 

conversion. , . , . „ 

• Outline typical steps in the conversion process, focusing particularly on 

procedures for library review of test files. 

• Specify effort (hours and rate) required to meet the conversion requiremen 
stated above if: 

a. All data is supplied in XXX format. TTCK^APr 

b. Bibliographic, holdings, and authority data is supplied in USMARC 
format, and all other data is supplied in XXX format. 

• Specify how long it will take to convert initial backfiles of data on a dedicated 

machine; list the specifications for that machine. 
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• Specify the process that will be used to update the initial database file with a 
subsequent load of all transactions occurring after the initial data extract and 
before cut over to the new system. 

9.1.4. Please supply a list of libraries whose data have been converted for use in the 



10. . Maintenance and Support (to be added later) 

[This is die place to discuss further MnLJN's access to source code and the plans the 
vendor has for responding to user needs and suggestions.] 

11. Documentation 

11*1. Staff Documentation User Manuals 

11.1.1. Each respondent is expected to describe in the proposal the type of user 
documentation it maintains for the system and the unit cost of this documentation. 

The successful vendor will be expected to supply a minimum of one complete 
printed user reference manual for each participating library. The vendor also is 
expected to provide online documentation and context sensitive help messages. It is fe, 
expected to be possible to customize online documentation, help screens, and pull- 
down menus to meet local needs. The cost of printed these manuals and online 

documentation is expected to be itemized and included in the cost of the proposed 
system r r 

Each respondent is expected to indicate in the proposal whether MnLIN has the 
right to make additional copies of user documentation and the type of user 
documentation that can be supplied in electronic form. 

The annual software maintenance fee paid by MnLIN is expected to cover the cost of 
regular updates and revisions to the user documentation manuals. 

1L1.2. Technical Documentation Manuals 

^ie vendor will be expected to provide 5 print copies of the technical 
documentation for the proposed system. This material is expected to describe in 
detail the operation of the system, including such activities as file backup, system 
initialization and restart, file restoration and recovery, file maintenance and record 
loading from tape, report and user notice production, etc 

12. Training 

12.1. Training Program v 
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Each respondent is expected to include in the proposal a description of the proposed 
training program. The description is expected to identify training personnel and 
outline their qualifications, length of training (e.g., number of hours), and 
provide a syllabus describing training content. 



12.2. Groups to be Trained . 

The vendor will be expected to train supervisory and administrative library 
personnel in each participating library in overall system work flow, operations, and 

troubleshooting. 



The vendor will be expected to train library public services and technical services 
personnel in each participating library in the use of all system functions for each of 
the functional modules. The number of persons to be trained in each library will be 
determined during contract negotiations. 



The vendor is expected to train computer operator(s) and system managers in 
hardware and software principles and system operation, maintenance, file backup 
and recovery, system security, software and database maintenance and management 
and report and user notice production. 



13. Transaction Response Time (to be added later) 



14. Acceptance Tests (to be added later) 



V 
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PREFACE 



RMC Consultants, Inc. has provided this proprietary Req uest for Proposal for MnlW 
sterns and Services to The State of Minnesota Library and Information Network (MnllNK). 

Please note from the Table of Contents that this RFP is organized into three Parts, and contains nine 
Sections plus Appendices. 

Part 1 (Sections 1 through 6) of this RIE provides information on the legal and administrative 
requirements of the RFP process; instructions to vendors on the organization, contents, and 
submission of proposals; specifications of configurations of systems and services for winch cos, 
proposals are requested; and lists of questions on a variety of top.cs of Particular interest to he 
State of Minnesota. Part I contains specific requests for information (Sectfons a and S) and 
questions of vendors (Section 6) to which vendors must respond in their proposals. 

Please note that "Section 5; Configurations and Cost Forms' specifies alternative configurations of 
required systems and services described by Sections 7, 8, and 9 for which cos, proposals are 
requested. The State of Minnesota will choose a combination of alternatives that the success u 
proposer will provide as a turnkey solution. 

The approach of describing comprehensive requirements in the sections of Part 2, and then 
identifying in Section 5 those specific components of systems and services for which cos, proposals 
are requested is based on the recognition of the following: 

(1 ) That it may not be possible or affordable for The State of Minnesota to satisfy all of its 
requirements at once, or through a single procurement process; 

( 2 ) That it is important for The State of Minnesota to obtain proposals that address 
comprehensive requirements as well as near-term priorities, in order to evaluate the 
suitability and longer-term prospects for proposed vendors, systems, and services; and 



(3) That until current technical and cost information is received through responses to this 
RFP. it wi || not be possible for The State of Minnesota to choose the best affordable 

combination of systems and services from the alternative and optional configurations 

described by Section 5. 

Part 2 (Sections 7, 8, and 9) presents general requirements and constraints for automated library 
systems and related services that are addressed by this E£E, and contains requests for infomatton 
and questions of vendors fas indicated by shaded text ) to which vendors must respond m thee 

proposals. 
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Sections 7, 8, and 9 also contain references to Appendices that contain either detailed information 
about key requirements, or document that The State of Minnesota does not have such 

requirements. 

Subsections within Sections 7, 8, and 9 may be annotated with the term 'NOT REQUIRED", to 
document decisions by The State of Minnesota that the functions, capabilities and services that are 

described by these subsections are not required. 

The Appendices in Part 3 have been defined to present detailed information and specifications for 
this RFP. Where pertinent information is either not applicable or unavailable for a given Appendix, 
the term "LEFT BLANK" has been inserted in the Table of Contents in order to document this. An 
additional explanation may be recorded on the title page for a given Appendix. 
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PART 1: 



RFP PROCEDURE > 
INSTRUCTIONS, AND FORMS 



The following sections provide information on the legal and administrative requirements of the RFP. 
process; instructions to vendors on the organization, contents , and submission of proposals; 
specifications of configurations of systems and services for which cost proposals are requested; 
and lists of questions on a variety of topics of particular interest to MnUNK Libraries. 
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NOTICE OF INTENT TO PROPOSE 



The State of Minnesota requests notification on or before Date, by completion and return of the form, of 
intent of vendor to submit a proposal in response to the Pom* fo r Proposal for MnUN< Ca t e ^t 
c r ..„. and Cervices. The State of Minnesota requests this information in order to plan for adequate review 

of proposals. 

Please fill out and return this form as provided below; responses may be returned by fax transmission. 




(1 ) Name of Firm Intending to Submit Proposal: 



(2) Name of Contact: 




(3) Telephone Number of Contact: 



(4) Signature of Representative of Firm: 



PI FASF RETURN THIS NOTICE TO: 

Name, Title 
Library 
Address 
City, State, Zip 
Voice: 

Fax: 
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INTRODUCTION 

The purpose of the Request for Proposal (hereafter "RFP") is to solicit proposals for MnUNK 
Gateway Systems and Services for the libraries and throughout the State of Minnesota (hereafter 
-Minnesota"). Administratively, libraries in Minnesota serve a current patron population of about 
XX, XXX, XXX citizens with library resources of more than xx,xxx,xxx items. Table 1-1 and ot er 
tables that follow provide statistical information about libraries in the State of Minnesota. 

OVERVIEW OF MnUNK AND MnUNK G ATEWAY SYSTEMS AND SERVICE S 

The State of Minnesota in this RFP represents the purchaser of systems and services to be 
■nplemenled and operated on behalf of both individual libraries and groups of libraries. MnUNK, 
the Minnesota Library and Information Network, represents that planning effort and that operational 
entity which has charge of defining, implementing, and maintainingsystems and services on behalf of 
Minnesota libraries which ultimately elect to utilize some etement MnUNK Systems and Services such 
as the MnUNK Shared System or MnUNK Gateway Systems and Services. In this document 
MnUNK represents a project, an entity in formation, and a set of systems and services for which 

the entity has responsibility. 

In brief the MnUNK Project seeks to allow users to access both traditional library material (e.g., 
print-form, etc) information resources - primarily those held in the collections of Minnesota hbranes 
or other libraries with which Minnesota libraries have cooperative arrangements - and d.grtal 
information resources available in electronic databases hosted on commercial systems and serv.ces, 
on servers located throughout Minnesota and globally on the Internet/WWW. 

MnUNK Gateway Systems and Services are defined as the set of components required to provide a 
single, easy to use, integrated, and coherent computer-based user interface. Such an interface 
provides for the end-user easily searchable access to and direct online access to or delivery of: 



( 1 ) 



( 2 ) 



Traditional Library Resources such as those described in Minnesota library 
Online Public Access Catalogs and in selected catalogs of libraries beyond 

Minnesota, 

Digital Resources, including 

(2.1) A variety of online Index, Abstract, Statistical, and Directory 
databases; 

(2.2) Minnesota based text, image, video, and multi-media resources 
available via Minnesota statewide network infrastructure; and 
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(2.3) Internet based resources from within and beyond the local 
institution's and Minnesota's network environment 

The Stale of Minnesota and its libraries regard integrated access to both forms of matenal as a 
necessity. Such access maximizes the ability of patrons to access existing materials in Minnesota 
libraries while assisting them in becoming literate, knowledgeable, and critical users of a wide array 

of digital information.. 

This Request for Proposal covers systems and services related to MnUNK Gateway Systems and 
Services that will allow users at personal computers via World Wide Web (“Web' or “WWW') 
browsers (e.g., Netscape, Mosaic, etc) at any MnUNK library and/or campus - or connected to 
any library and/or campus network, or remotely via the Internet - to search for wanted rnfomatton 
in the collections of Minnesota libraries, LAN/WAN accessible digital resources, databases teemed 
by MnlINK, as well as digital resources available through the Internet/World Wide Web. 



MnUNK Systems and Services include: 

(1 ) an End-User Client Workstation configured as a World Wide Web client Such a 
workstation may be either a graphically oriented microcomputer workstation or 
Network Computer with graphical Web browsing capability. For purposes of ADA 
compliance and compatibility with the existing installed base of terminals, MnUNK 
will support terminals which can emulate VT100 terminals via Lynx, a capability for 
supporting computer terminals which access World Wide Web resources. Libraries 
are expected to invest in graphically oriented workstations now and in the future. 

(2) MnUNK Gateway Servers which stand between end users at workstations and a 
variety of target databases, systems, and services. The MnUNK Gateway Servers 
have responsibility for identifying, authenticating, and authorizing users, for 
maintaining information about the state of a user's interaction with one or more 
databases, systems or services, for supporting a World Wide Web user 
environment at the workstation, and for supporting a variety of open standard 
computer protocols for the search, retrieval, and processing of information obtained 
from target sources. Gateway Servers may be dedicated to a single library or shared 
among several libraries. 

(3) A MnUNK Union Catalog which identifies the library material owned by participating 
libraries using conventional cataloging records. For such materials, the MnUNK 
Union Catalog can respond to a user's search with information about titles of works 
which match the user's search criteria, which libraries own such materials, detailed 
information about the component physical pieces which make up a title, and 
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information about the current availability of such pieces in each owning library. The 
MnUNK Union Catalog either may exist as a single, centralized, shared system or 
may function as a distributed "virtual" Union Catalog in which Gateway Server 
software in real time searches a number of online public access catalogs and 
composes a response to a user's search criteria. 

A MnUNK Shared System which provides automated integrated library system 
services to participating libraries, in the form of circulation control, acquisitions, 
serials control, online public access catalog, interlibrary loan, and other functions. 
The MnUNK Shared System may or may not host a MnUNK Union Catalog 
depending upon a number of factors. The MnUNK shared system itself may consist 
of a single, centralized host system or a distributed system with multiple host 
computers each serving a library or group of libraries. The MnUNK Shared System 
represents a key component in an overall strategy which allows individual libraries 
to cooperate with each other in a number of areas, such as collaborative collection 
development and interlibrary loan. For example, Interlibrary Loan Server software 
takes responsibility for assisting library staff in fulfilling interlibrary loan requests 
from client software resident on the MnUNK Gateway Server. 

MnUNK Value Added Systems and Services consist of databases, systems, and 
services accessible via the MnUNK Gateway architecture. Such systems and 
services, offer services beyond the MnUNK Gateway System, the MnUNK Union 
Catalog, and the MnUNK Shared System. Such services m ay include licensed online 
subscription databases, pay per view databases, an Internet index or catalog, 
interlibrary loan services external to MnUNK, document delivery services. MnUNK 
will determine which services to add or withdraw from such a menu of databases, 
systems, or services and/or the terms on which such a service is available (shared 
subscription or pay per view or use). MnUNK will utilize open systems computer 
and communications protocols for purchasing such services; vendor who seek to 
do business with MnUNK will need to provide their services in such a manner that 
such an open systems environment is maintained* 

MnUNK Participating Library Z39.50 Servers. Libraries participate in MnLINK 
through use of the MnLINK Shared System and/or by making information regarding 
their collections, their detailed collection holdings, and the availability of those 
holdings known to MnLINK users. MnLINK Libraries which have automated library 
systems and for whatever reason do not participate in the MnLINK Shared System 
must acquire MnLINK Z39.50 Server capability sufficient to make information about 
their collections and holdings available to MnLINK users. 
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MnUNK end users will gain access to MnUNK systems and services via a World Wide Web 
compatible workstation environment. A MnUNK Gateway Server will identify, authenticate, and 
provide authorization of MnUNK users - wherever such us.ers may gain access to Gateway 
Systems and Services - the local library and/or campus, Minnesota statewide networking 
environment, or via the Internet. The point in a user session at which a user must undergo such 
authorization must be subject both to initial control and subsequent modification by designated 
MnUNK System Administrators, based upon changing needs to limit or control access to one or 
more or all features accessed via Gateway capabilities. The MnUNK Gateway must have the 
capability to allow designated MnUNK System Administrators to define and maintain multiple user 
interfaces as well as the ability to invoke a default user interface deemed appropriate for a user 
based upon that user's type as determined via the authorization process. 

Via the Z39.50 Vers bn 3 Search and Retrieval Protocol, the MnUNK Gateway Server will provide 
access to a variety of catalog and index type services and databases (including a MnUNK Union 
Catalog including both library holdings and item availability information maintained by bcal 
automated library systems, an index of Internet resources (including World Wide Web resources), 
other subscription and pay-per-view databases), directly displayed content resources (e.g.. digital 
information which able to be displayed or played at the user Web workstation from Minnesota 
network based digital resources or Internet sources) and delivery type services (e.g. mterlibrary 



The MnUNK Gateway should be extremely flexible. Designated MnUNK Systems Administrators 
must have the ability to profile the target servers to be searched as a group, to create one or more 
HTML search forms as the front end of the MnUNK, and to modify authorization groups and 
classes as needed to extend or restrict privileges to various groups of potential users. 

Using a MnUNK Union Catalog a user will be able to locale and request interlibrary loan of materials 
located in MnUNK library collections and in libraries beyond Minnesota. 

A single search (and in some cases the same search that is made of the Union Catalog) must also 
have the capability to conduct the user to other analog and digital resources beyond those in the 
Union Catalog, including library resources of libraries not a part of the union catalog as well as digital 
resources throughout Minnesota, Global WWW resources, subscription type licensed databases, or 



MnUNK Shared System Libraries will make collaborative use of automated library system services 
from a single vendor. In a similar manner to its decision regarding the architecture of a MnUNK 
Union Catalog, MnUNK will determine whether such a Shared System will consist of a single. 



loan, commercial document delivery, etc.), 



pay-for-view" database services. 
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centralized computer configuration or a distributed system based on elements of feasibility, 

( functionality, performance, and cost which form part of its criteria for the selection of a vendor for 

the MnLINK Shared System. 

Those libraries which do not participate directly in the MnLINK Shared System and which have 
automated library systems in place may join in the overall resource sharing framework of MnLINK 
by purchasing and implementing NISO and ISO Z39.50 Server capabilities for use with their 
systems. MnLINK, the MnLINK Gateway vendor, and the Union Catalog and Shared System 
vendors will need to work together to determine the interoperability of various components. 
MnLINK cautions libraries that the Z39.50 Servers required for participation in MnLINK must 
implement Version 3 of the protocol and must interoperate successfully with the to be chosen 
vendor's or vendors' systems and services. 

MnLINK will determine on an ongoing bass the systems and services which it will purchase on 
behalf of MnLINK Libraries as Value Added Systems and Services. Such databases, systems, and 
services, in a manner similar to automated library systems of participating local libraries, will also be 
required to interoperate with MnLINK's Gateway, Shared System, and Union Catalog components. 

By and large MnLINK Gateway Systems and Services are intended to consist of off-the-shelf 
hardware and software components that have been implemented within the library and information 
© industry - including the automated library systems and World Wide Web sectors. These 

components will include new modules to be added to existing automated library systems at some 
libraries and campuses, some new systems and services, and in some cases replacements for older 
library systems that have become obsolete. 

With the stress today upon budgets to maintain adequate library resources, the recommended 
information infrastructure and goals for coherent access to information resources - both traditional 
library material (print-form, etc) as well as digital - are designed to yield the best possible return on 
investments in library programs, materials, operations, technology, and access to information. 
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6 QUESTIONS FOR RESPONSE 

Proposers must provide written narrative response to the following questions (see Section 4.4: 
Instructions for Part 4 of Proposal). In your response, phase repeat each question with your 
answer, as a convenience to readers, numbering the questions and answers as shown. 



6. 1 QUESTIONS REGARDING APPUCA TIONS SOFTWARE REQUIREMENTS 



6.1.1 Questbns Regarding Specific Software Modules 

(1) What software and subsystems not now available must the proposer provide in order to 
implement the system that it proposes? Plans for development of this software and future 
subsystems, including dates of availability, should be described according to Section 4.3. 

(2) Please describe which aspects of the system (parameters) are susceptible to modification 
either by the vendor or by the library. How will the library set the parameters for each 
module/subsystem? Please describe how parameters are set for each subsystem. Indicate 
whether the parameters can be set and changed online as a system function or whether the 
parameters must be defined and set as part of system installation. 

(3) Does proposer's union catabg store authority data in conformance with US/MARC formats 
for authority needs? Please explain the formats proposer's system uses for authority data, 
and if and how US/MARC authority data can be applied to update the system s authority 

records. 

(4) How does the proposer's union catalog authority control system prevent the occurrence of 
blind cross-references? 



/ 

(, 



(5) Is proposer's union catalog system forgiving of users' mistakes, such as misspelled terms 
that are input to make queries? Please explain your answers. 

(6) Does the union catalog system treat common misspellings in a manner which informs the 
searcher of a transfer to the correct spelling, then transfers him? 

(7) Can the union catalog system store a limited number of standard searches on topics 
searched very frequently (online pathfinders)? 

(8) Can the union catalog system look for the entered term as the beginning of a longer string of 
data without an explicit truncation symbol ($)? 

(9) Does the union catalog system search for both singular and plural forms of words entered? 

(10) Does the union catalog system remove common suffixes when patrons enter them in 
complete form (librarians hip, librarians, etc.)? 

(11) In the union catalog system would initial articles in foreign languages be omitted as they are 
in English? If so, can there be exceptions, e.g., Los Angeles, El Paso? Would we have the 
ability to choose, on a case-by-case basis, whether we wanted them omitted or not? 

(1 2) What is the length of the time-out feature, if any, on union catalog workstations? May library 
staff set this time? 
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M3) Describe the ability of the union catalog to provide help screens in languages 

‘ En*feh Wha, languages are supported! How does a user radiate to the system that he or 

she wishes to use a non-English help screen? 

and the system retrieves too many hits to display them all.) 

(1 5) What means is there within union catalog by which a user may determine a library's location, 
address, telephone number, and hours of operation? 

(16) Can proposer describe how its union catalog makes use of different levels of bibliographic 
record displays? 



5.7.2 Questbns Regarding Records ,. Data Files, and Database(s) 



( 17 ) 



( 18 ) 



( 19 ) 



{ ■ 



ERIC 



( 20 ) 



Describe the various statuses that can be set and maintained on user authoriz at lon re cords 
\n the MnLINK Gateway System. What statuses are there, how are they invoked and which 
ones a^ seEor unset automatically by the system, which can be set or reset by author.zed 
librarv staff and which ones are dependent upon another status haying already been set 
and fitedV ^Does the library have a choice in how each status is worded, whether and how it 
appears in the authorization procedure? 

Can proposer's system batch-bad bibliographic records in the US/MARC format, detect 
duDlication with records in the Bibliographic Database, and process the incoming and 
existing records to avoid unwanted duplicatbn of bibliographic records? Can P r °Pp s ®^ 
system^ batch-bad authority records in the US/MARC and Minnesota Serais Union Catalog 
f<Sm at without pre-processing by another computer? Please explain your answer. 

If "no," please explain how to avoid or correct unwanted duplicatbn of bibliographic 
records. 

If "yes " please explain if and how such input can be made during periods of interactive use 
of the system, and if and how response times would be impacted. 

If "yes," please specify how many records-per-hour can be input both in dedicated batch 
mode and during periods of interactive system use. 

Will proposer please explain if, how, and whether proposer's system can output files of 
bibliographic, authority, and other user-oriented data onto magnetic tape? 

If "yes," please explain if and how such output can be made during periods of inter-active 
operation of the system, and if and how response times would be impacted. 

If "ves " please specify for each type of file how many records-per-hour can be output to 
magnetic Tape both in dedicated batch mode and during periods of interactive system use. 

If "yes," please specify for each fib the particular MARC format in which it can be output 

If "ves " will proposer provide MnLINK with software and necessary documentation and 
irainfng to batch output onto magnetic tape bibliographic records and authorrty records in 
such a way that these records can be transferred to another system ? 

How may bibliographic records be created and updated in proposer's union catalog 
system? 
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6.2 



( 



Mow k oroDOser's system updated and maintained in order to acrommodate ongoinR 
changes in the US/MARC formats and how does or will the vendor deal with M orm 
integration? 

( 22 ) please describe any print constants or labels supplied by the system ^en bibfoRraphk: 

U2) "ecords are beinR viewed by patrons. For eyample when dep^nK teH S05 e aJbW 

curb as "Contents:" visible to patrons? Or for a field 520, a summary. ‘ > 

about labels for "author," "title," "composer," "call number," "location, subject, e c. 

(23) Does the proposer's system use filing indicators contained in the MARC records for 
searching and alphabetizing the appropriate fields? 

(24) How does the proposer's system treat a title found in a subfield t (of a 6XX or 7XX tag, for 
example), when that title begins with an initial article? 

(25) How is database maintenance (file reorganization, backup, etc.) performed in proposer's 

‘ system for Bibliographic files, Authority files, and other files? 



Questions Regarding Technical Environment 



( 26 ) 



( 27 ) 



(28) 



(29) 



( 30 ) 



( 31 ) 



What warranties does proposer provide on the installed and accepted system, in P a ^ and in 
" SnR processors ), P disk driyes, workstedon dw-JjJ** 
equipment, telecommunications equipment, printers, and data «pture dev.cesc^vvna 
warranty is given for software? What procedures are provided for filing warranty clams, 
consideration of them, and resolution of them? 

Is proposer willing to interface its union catalog and MnUNK Rateway server *£*™?*f 
other* vendors' automated systems) If so, what will be requrred of proposer and of other 

parties to make such interfaces? 

Is the proposed system capable of interfacing with a local area network? If so, with what 
LAN software (for instance, Novell) is the system compat.ble? ,s t ^P r ° P °^ ar ^ {for 
capable of interfacing with LAN/WAN software? If so, with what LAN/WAN software (tor 

instance, TCP/IP) is the system compatible? 

Can MnUNK workstations be equipped to allow disabled patrons i-^pH v^o^ C |ack o" 
rataloe? Are specialized devices available which permit users with limited vis ion, lac:K ot 

mTnu5 dexTe,i, P y! or other disables .o use features availabia ^a^b^ * 

so, please describe the capabilities and quote costs on a per-workstation basis. 

Would propoaer ptease describe the locatbns from which P^rwouH SlVf^ 
hardware and software maintenance and support services, and the p ; ton anr#» 

nmvkfon of these services? Please describe vendor's preventive hardware maintenance 
prog ams and mefhoTused to detect and remedy latent failures Which procedures . any 

Sre downtime? How soon will critical parts be available or .nstaHation , in MnUNK s 
system? How soon will non-critical parts be available for installation in MnUNK s system? 
Does proposer have multiple sources for obtaining parts? 

Does proposer maintain a "trouble-desk" service with a toll-free phone number? If "yes," 
£ how Tany hours per day, and days per weekf Am there any restnctons on whrch 
MnUNK or MnUNK Library staff may place a call? 
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(32) 

(33) 

(34) 

(35) 

(36) 

(37) 

(38) 



u a remote console facility available allowing system operators to diagnose and corrert 

minor problems from a remote location! What security «*' J °' b jCMP bw^d 

Can dial-back modems be usedi Can a workstation connected to a Mmnesota TCP/IP based 

LAN/WAN Network Environment or the Internet via a constant connectio 

Should any spare peripheral devices be included in the system purchase price? If so, how 
many spares does vendor suggest the library keep on hand? 

Is pre-installation training using an Internet based set of MnLINK Gateway and/or Union 
Catalog Servers/Services to simulate system use available? 

What oDeratine system is used? What are the strengths and weaknesses of this OS? Is the 
ooe rabne s ys tern 'designed for a real-time environment where, in the event of some type of 
crash, the system can be brought back up with all files intact m a short period of time? 

How is proposer's system protected against unwanted access and use by computer 
"hackers?" 

How much staff will MnUNK and MnUNK libraries need for system «mplemon,atk.n, system 
management, and computer operations for the system that proposer has proposed! 

How much space and of what type will be needed to accommodate any systems proposed 
by the vendor! What factors should govern the location and oversight of any an 
systems or system components? 



m 



6.3 Other Questions 

139) Describe the proposed m igration from current arrangements in Minnesota to the P r °P° ser /* 
(39> sySem detailing which files will be migrated, the order in which fifes wni be transferred the 
vJay in which final cutover will occur, the means of capturing bibliographic and °^eMypes 
of ^ the length of time for each phase of the migration pro|ect, and the amount of 

downtime (if any? which each and every MnUNK library and/ °^ P ^ 

When transferring data from the present system to a new system, what guarantee aoes 
MnLINK and MnLINK Libraries have of not losing information in their existing database? 

(40) Will MnLINK Libraries be able to use existing encoding for m been 
proposer's system be used with MnLINK Libraries 1 machine-readable labels that have been 

applied to its materials 
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6.4 




SPECIA L QUESTIONS ON CLIENT/SERVER ARCHITECTURE 



( 41 ) 

( 42 ) 

( 43 ) 



( 44 ) 

( 45 ) 



( 46 ) 



( 47 ) 



Please Rive your definition of "Client/Server Architecture." 

Please explain how the system(s) that you have proposed are or are not based on 
client/server architecture. 



For each of your applications modules, please explain the status of your development of 
Web clients, or of your plans to develop Web client modules for personal computers, r tease 
indicate the operating system environments (e.g., Windows, Windows 95, Windows NT, 
Macintosh, etc.) for these clients. 



Can the proposer provide a single interface to access both the union catalog and Internet ! 

Is the proposer's system conformant right now with version 3 of the 239.50 standard! 

If "no," how soon can the proposer guarantee that to be available, and at what cost! 

If "y es " please describe Z39.50 client modules that can be operated on MnLINK Gateway 
Server' computers, and the Z39.50 server modules that can be operated on servers m 
conjunction with local integrated library systems and OPACS. 

Have you tested or implemented into production operations a graphical Web browser 
interface to a Gateway Server as described by this MnLINK RFP i 



If "yes," would you please describe how a given user at a graphical Web station is 
connected to the Gateway Server! 

For such connection, please describe whether or not session is established, and how each 
query transaction handled. 

Would you please describe the differences in response-time performance and transaction- 
volume throughput between access to your union catalog through your proprietary 
graphical interface vs. a graphical Web browser ! 

Would you please describe if and how the use of a graphical Web browser to access your 
union catalog has affected your software licensing or product pricing policies ! 
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PART 2: 



SYSTEM REQUIREMENTS 



Part 2 (Sections 7, 8, and 9) presents general requirements and constraints for automated 
library fy tTms and related services that are addressed by this R£Z and contains ; requests for 

information and questions of vendors to which they must respond ,n * he,r P'°. p ? s ^ s : t . 

7 8, and 9 also contain references to Appendices that contain either detailed /n/bmtaDon afwuf 
key requirements, or document that MnUNK does not have 

within Sections 7, 8, and 9 may be annotated with the term NOT REQWBm J 

MnLINK's decisions that the functions, capabilities, and services described by these 

subsections are not required. 

The approach of describing comprehensive requirements in the 

identifying in Section 5 those specific components of systems and services for which cost 
proposals are requested is based on the recognition of the following: 

(1) That it may not be possible or affordable for The State of Minnesota to satisfy all of its 
requirements at once, or through a single procurement process; 

(2) That it is important for The State of Minnesota to obtain proposals that address 
comprehensive requirements as well as near-term priorities, in order to evaluate the 
suitability and longer-term prospects for proposed vendors, systems, and services, and 

(3) That until current technical and cost information is received t/jrou^hresponsesfofh/s 
RFP it will not be possible for The State of Minnesota to choose the best affordable 
combination of systems and services from the alternative and optional configurations 
described by Section 5. 
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Section 

Number 

7.0 

7.1 

7.2 

7.3 

7.4 

7.5 

7.6 

7.7 



CONTENTS OF SECTION 7 



Section Name 

Overview 

General System Description 

FIGURE 7-1 MnUNK GATEWAY COMPONENTS: ONE POSSIBLE VIEW 

MnUNK End-User Client.: 

MnUNK Union Catalog System/Service 

MnUNK Gateway Server and The Search and Retrieval Client 

Interlibrary Loan Management System 

Document Delivery Application Client 

Management Information Syslem/Report Generator 
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A PPLICA TtON SOFTWA RE REQUIREMENTS 



l 

7.0 OVERVIEW 



This section presents a narrative overview of comprehensive, long-range requirements for the type 
of integrated systems and services appropriate for Minnesota's long-term use as a MnUNK 
Gateway. The following sections give brief overviews of each of the desired software systems, 
subsystems, or modules (these terms are used variously and interchangeably). 

The intent of this section is to describe what a suitable MnLINK library system should do and be, 
but not how it should perform various functions. The distinction between what a system should 
do and flow it should do it is the distinction between requirements and specifications. 



Each computer system has its own, unique specifications. It is possible for several computer 
systems with different designs and specifications to fulfill the same set of library system 

requirements. 

By working at a requirements level, the MnLINK Project can focus on what a system should do for 
individual Minnesota libraries as well as Minnesota libraries and their users as a whole, leaving the 
jp technical work of detailed computer system design and specification to the vendors who devebp 

particular systems. For the MnLINK Project to work at the level of specifications is tantamount to 
their saying exactly how a system should be designed and implemented - which goes beyond the 
experience and skills of individuals who are not library systems analysts and developers. Unless a 
library or libraries know precisely which automated system it or they wish to implement, the libraries 
in question should work at the requirements level, and await the vendors' proposals, system 
descriptions, and technical documentation to provide specifications of particular computer systems 
to the library's stated requirements, in order to identify the system believed to be most suitable. 

Please note that Section 5 of this RFP specifies alternative configurations of required systems and 
services for which cost proposals are requested. MnLINK will choose a combination of alternatives 
that the successful proposer will provide as a solution in response to MnLINK defined issues and 
requirements. 

Please note that each proposer shall annotate with detailed and explicit narrative information the 
deviations of proposed systems from the requirements presented in Sections 7, 8, and 9, and 
should answer questions and requests for information that are contained in the texts of these 

( sections. 
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(1 ) What software and subsystems not now available must the proposer provide in order to 
° ’ irnptemenuhe system thatit proposes? Plans for developrnent of this software and future 

subsystems, including dates of availability should be described in conun^ion with 
requirements stated in each section according to criteria such as COMPLIES with 
Reauirement based on Existing System Capability in Production Release Since 
DEVIATES from Requirement based on Existing System Capability in ^ Auction Release 

Since (Date) Complies Based on System Capability LINDER DEVELOPMENT and Projected 
for Rek^e (DA W, Capability PLANNED for Release (DA TE), NOT PLANNED. 

(2) Please describe in the response to each section which aspects of the system jP^ameters) 
are susceptible to modification either by the vendor or by the library. How will the library 
set the parameters for each module/subsystem? Pleasedescr.be how parameters are set for 
each subsystem. Indicate whether the parameters can be set and changed onl.ne as a 
system function or whether the parameters must be defined and set as part of system 

installation. 
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The desired system for MnLINK is an online, real-time library Gateway System and/or Service that 
presents a single-user interface to a number of databases, systems, and services, including: a 
MnLINK union catalog, other library catalogs or union catalogs, digital information resources via an 
Internet Index, subscription database services, and services (such as pay per view database access, 
interlibrary loan, and document delivery). The MnLINK Environment represents a information 
strategy which will unfold over time which: 




puts in place a major capability for cooperative library resource sharing in Minnesota in the 
form of the MnLINK Shared System, 

preserves and enhances investments in existing systems of libraries which do not participate 
directly in the MnLINK Shared System through retrofitting such systems, where feasible and 
cost effective with standard NISO Z39.50 search and retrieval server capabilities, 

capitalizes on the universal adoption of TCP/IP protocols and World Wide Web protocols 
such as HTTP, HTML, etc. in their successive versions and in new 'Web" type protocols as 
they emerge, 

further capitalizes on the international adoption of the Internet and Web based NISO and 
ISO Z39.50 protocol for search and retrieval of information from library catalogs, abstract 

and index, and full text sources, 

lays the framework for multimedia content delivery via graphically oriented microcomputer 
workstations and emerging simplified network computers both using Web browser client 
technology, while providing text based access from and to the installed base of terminals 
serving both the general population as well as those with visual or hearing disabilities 
through specialized hardware and software based on text processing, 

establishes an open system and standards environment which does not constrain MnLINK 
or individual libraries in their choice of vendors, systems, and services now or in the future, 

provides the capability to serve Minnesota users of MnLINK at home, in the office, in the 
library, on campus, in a distance learning environment, or while traveling, 

allows a MnLINK administrative organization to integrate, manage, and tune user access to 
and use of a diverse and changing set of databases, systems, and services through gateway 
architecture which can provide for the development, implementation, and refinement of 
coherent sets of policies on a statewide basis. 
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The basic components of the overall Mnl.INK System and Service Configuration include a (1) World 
Wide Web based End-User Client Workstation, (2) a Gateway System and/or Service, (3) a MnUNK 
Union Catalog System/Service, (4) a MnUNK Shared System consisting of one or more Shared 
System Servers and corresponding Staff-Oriented Workstations tailored for use with the Shared 
System, and (5) MnUNK Value Added Systems, Databases, and Services (such as subscription and 
pay-per-view databases). A sixth component, Z39.50 Servers for local systems form a part of the 
overall architecture, but are not the subject of this procurement. Figure 7-1 illustrates the MnUNK 
Environment for Systems and Services. Brief component descriptions follow: 

an End-User Client Workstation configured as a World Wide Web client. Such a 
workstation may be either a graphically oriented microcomputer workstation or 
Network Computer with graphical Web browsing capability. For purposes of ADA 
compliance and compatibility with the existing installed base of terminals, MnUNK 
will support terminals which can emulate VT100 terminals via Lynx, a capability for 
supporting computer terminals which access World Wide Web resources. Libraries 
are expected to invest in graphically oriented workstations now and in the future. 

MnUNK Gateway Servers which stand between end users at workstations and a 
variety of target databases, systems, and services. The MnUNK Gateway Servers 
have responsibility for identifying, authenticating, and authorizing users, for 
maintaining information about the state of a user's interaction with one or more 
databases, systems or services, for supporting a World Wide Web user 
environment at the workstation, and for supporting a variety of open standard 
computer protocols for the search, retrieval, and processing of information obtained 
from target sources. Gateway Servers may be dedicated to a single library or shared 
among several libraries. 

A MnUNK Union Catalog which identifies the library material owned by participating 
libraries using conventional cataloging records. For such materials, the MnLINK 
Union Catalog can respond to a user's search with information about titles of works 
which match the user's search criteria, which libraries own such materials, detailed 
information about the component physical pieces which make up a title, and 
information about the current availability of such pieces in each owning library. The 
MnLINK Union Catalog either may exist as a single, centralized, shared system or 
may function as a distributed "virtual* Union Catalog in which Gateway Server 
software in real time searches a number of online public access catabgs and 
composes a response to a user's search criteria. 
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A MnLINK Shared System which provides automated integrated library system 
services to participating libraries, in the form of circulation control, acquisitions, 
serials control, online public access catalog, interlibrary loan, and other functions. 
The MnLINK Shared System may or may not host a MnLINK Union Catabg 
depending upon a number of factors. The MnLINK shared system itself may consist 
of a single, centralized host system or a distributed system with mult'pJe host 
computers each serving a library or group of libraries. The MnLINK Shared System 
represents a key component in an overall strategy which allows individual libranes 
to cooperate with each other in a number of areas, such as collaborative collection 
devebpmenl and interlibrary loan. For example, Inlerlibrary Loan Server software 
takes responsibility for assisting library staff in fulfilling interlibrary loan requests 
from client software resident on the MnLINK Gateway Server. 



(5) MnUNK Value Added Systems and Services consist of databases, systems, and 
services accessible via the MnLINK Gateway architecture. Such systems and 
services, offer services beyond the MnLINK Gateway System, the MnLINK Union 
Catabg, and the MnLINK Shared System. Such services may include licensed online 
subscription databases, pay per view databases, an Internet index or catalog, 
interlibrary loan services external to MnLINK, document delivery services. MnUNK 
will determine which services to add or withdraw from such a menu of databases, 
systems, or services and/or the terms on which such a service is available (shared 
subscription or pay per view or use). MnLINK will utilize open systems computer 
and communicalbns protocols for purchasing such services; vendor who seek to 
do business with MnLINK will need to provide their services in such a manner that 
such an open systems environment is maintained. 

(6) MnUNK Participating Library Z39.50 Servers. Libraries participate in MnLINK 
through use of the MnLINK Shared System and/or by making information regarding 
their collections, their detailed collection holdings, and the availability of those 
holdings known to MnLINK users. MnLINK Libraries which have automated library 
systems and for whatever reason do not participate in the MnLINK Shared System 
must acquire MnLINK Z39.50 Server capability sufficient to make information about 
their collectbns and holdings available to MnLINK users. 



The End-User Client Workstation consists of any hardware platform which can run World Wide 
Web browser client software. Such workstations include Windows type microcomputers, Unix 
workstations, MacOS microcomputers, as well as Network PC workstations. The control of the 
interface and the capabilities which the user has via the End-User Client is a function of the HTTP 
Server component of the MnLINK Gateway Server. At the Client Workstation the user must have 
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capabilities for searches of the MnUNK Union Catalog and a variety of other databases accessible 
principally and primarily via Z39.50 supplemented by use of other standardized or proprietary 
protocols, agents, or search engines which provide coverage of databases, systems, and services of 
interest to MnUNK. Through the use of the Client the user must be able to invoke the display of 
holdings, status, and availability information for an item or items of library material; its inter-library 
loan within and beyond Minnesota, as well the provision of such material by a commercial document 

delivery service. 



For digital type resources the End-User Client Workstation must have the ability to display a Web 
based searching environment, to display of bibliographic and/or index information, to display Web 
addresses specifying the location of digital content described either in a bibliographic record or 
another Web page, to allow point and click selection of such network addresses, to utilize such 
information to locate, retrieve, display, and play a digital resource directly without intervening 
assistance from the MnUNK Gateway Server. 




( 



The MnUNK Union Catalog System/Service provides user searching of and retrieval from a MnUNK 
Union Catalog comprised of bibliographic databases from participating MnUNK libraries. The 
MnUNK Union Catalog must have Z39.50 Version 3 Server capabilities. The Z39.50 Server will 
albwthe MnUNK Union Catalog to interface with MnUNK Gateway Servers. 

The Gateway supports a Web (HTTP and other Web based protocols) based environment at the 
end user workstation, provides methods for access control and session management, and provides 
interfaces to target databases, systems and services - one of which consists in NISO Z39.50 
compliant catalogs and databases. With respect to access control the MnUNK Gateway Server 
component identifies and provides Network Authentication and Authorization of MnUNK users 
(wherever such users may gain access to MnUNK— the local library and/or campus, the MnUNK 
TCP/IP based LAN/WAN network environment, or via the Internet) such that a user so 
authenticated may make use of any and all local and remote services for which that user is 
authorized (from the MnUNK Union Catalog, other Z39.50 accessible library catalogs, an Internet 
Index, MnUNK or local library licensed subscription databases, interlibrary loan, document delivery, 
and pay per view databases) via a single authentication and authorization process. The 
authentication and authorization services should allow designated MnUNK Gateway Systems 
Administrators to script the conditions under which the Authentication/Authorization process must 
take place and to change such scripting as policies governing various systems, services, and 
resources as policies change. The authentication and authorization services will provide an 
important means for MnUNK to tune the performance of MnUNK Systems and Services as a whole, 
extending or restricting access to various search profiles and services as policy or available 
resources dictate. 
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With respect to session control the MnLINK Gateway maintains the state of a user's search with 
respect to the one or more target databases in order that the user may navigate the search results 
and refine a search by adding criteria or performing set operations on search results. 

The MnLINK Gateway Server will provide access to a variety of databases, applications, systems, 
and services via standard communications protocols such as NISO Z39.50. Such resources 
include: the MnLINK Union Catalog, status and availability information for each individual title held 
by a MnLINK library, an Internet index and/or catalog, subscription and pay-per-view databases, 
interlibrary loan, commercial document delivery, and other types of applications, systems, and 

services. 

The kind of system that is described by this document is an "integrated set of MnLINK Systems and 
Services" whose design is based on open systems and standards and takes into account the basic 
interrelationships of bibliographic and other data and processing functions found in automated 
library systems and services. MnLINK Systems and Services must have excellent growth potential 
with respect to the addition of other libraries and of new functions, increase in processing power 
and capabilities for transaction throughputs, addition of online data storage, and added numbers of 
workstations, without degradation to response time. 

• The applications modules - or subsystems - for which cost proposals are requested by the State of 
Minnesota are specified in Section 5 of this RFP. 
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7.2 MNUNK END-USER CLIENT WORKSTA TION SOFTWARE 

Individual users shall have the ability to gain access to the MnUNK Gateway Server from any point 
at which an Internet or a TCP/IP based MnUNK LAN/WAN network connection may be made, 
including direct connections from a participating MnUNK Library, various desktops connected to a 
library and/or campus network or the MnUNK LAN/WAN network environment, other desktops 
connected to the Internet, as well as SLIP or PPP dial-up locations. Except for connection speed, the 
MnUNK Gateway Server interface shall function identically for the user from anywhere it is 

accessed. 

The MnLINK End-User Client Workstation Software environment consists of a World Wide Web 
browser client. The MnLINK Gateway Server must support a World Wide Web browser Client or a 
character oriented WWW browser interface such as Lynx. 




The HTTP Server component of the MnLINK Gateway Server must provide at the End-User Client a 
variety of searching modalities and service offerings to an end-user whether such a user has novice 
or advanced searching abilities. Users should have differential privileges with respect to access to 
MnLINK Systems and Services based upon individual circumstances (e.g. registered MnLINK user or 
not) and user type (e.g. library staff or library patron). 

The MnLINK Gateway should allow designated System Administrators to script the circumstances 
under which a user must identify and authenticate themselves and to determine for which systems 
and services a user must receive authorization. The MnLINK Gateway must allow for circumstances 
in which no user identification is required, such as users which originate a network connection from 
a known network addresses associated with a specific library or campus location. The MnLINK 
Gateway must albw System Administrators the option of defining a set of user privileges, if any, 
which maybe provided to an unidentified (or anonymous) user.. 

For traditional library resources, such as books, serials, films, microfiche (hereafter "analog 
resources") the MnLINK End-User Client Workstation must display information about such 
resources in response to a user search of the MnLINK Union Catalog and other MnLINK databases. 
The MnLINK End-User Client Workstation must have the capability to display for such resources 
bibliographic information, holdings, status, and availability. The End-User Client must provide for 
the interlibrary loan of such material or its delivery via commercial document delivery service. For 
digital resources, the End-User Client Workstation must have the capability to display and play 
directly all forms of text, graphics, and multimedia types commonly recognized on the Internet and 
the World Wide Web. 



The interface presented at the End-User Client, the target catalog and database services, and the 
services accessible will turn on the user type. MnLINK must have the capability to create and 
modify service profiles for each user type, consisting of the search interface and help capabilities to 
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be presented, the identity and number of target catalog and database servers to be addressed in 
parallel, and the services to which a user type may gain access. Users must have some capability to 



authorization to gain access to any resource available via MnLINK. MnLINK must harve the 
capability to modify its policies governing access to MnLINK resources and the service profiles of 
various user types as MnLINK gains experience with the use of its systems and services. 

The End-User Client must exhibit compliance with the Americans with Disabilities Act and operate 
with assistive software or devices such as large printed interfaces, voice activated input, alternate 
keyboard or pointer interfaces, etc. The End-User Client interface design must accommodate users 
who do not speak English, but who speak and/or read a language other than English. 



modify such service profiles immediately to meet their searching needs and with proper 
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7.3 MNLINK UNION CATALOG SYSTEM/SERVICE 

The MnLINK Union Catalog System/Service provides the capability for conducting search and 
retrieval against a Minnesota Union Catalog comprised of bibliographic databases from MnLINK 
participating libraries in MARC record form, including cataloging records. Union List of Serials 
records, and other MARC based bibliographic records such as those containing table of contents 

information. 

Much of what appears in this section and elsewhere in this RFP draws upon understandings of the 
Union Catalog as a single, centralized database and corresponding software functionality. Database 
and system architecture admit of a number of methods of distributing catalogs from replication of the 
complete database to various forms of segmentation. Each of these methods has advantages and 
disadvantages. However, the model of a single, centralized Union Catalog database offers the most 
clear-cut case for understanding user and library requirements without attempting to make complex 
technical assumptions which verge on system design. In terms of database management, database 
integrity and quality, reliability and the costs of achieving reliability, comprehensive scope, and 
prospects for bringing together various copies and forms of a single work, the Union Catalog model 
has not given ground to the alternatives. However, MnLINK has not deckled whether such a Union 
Catalog System / Service will reside on a single, centralized computer configuration or in a distributed 
system environment. MnLINK will decide such an issue based on elements of feasibility, 
functionality, performance, and cost which form part of its criteria for the selection of a vendor for 
the MnLINK Shared System. Therefore MnLINK requests that vendors propose alternatives which 
the vendor believe to be responsive to MnLINK's criteria for the selection of a Union Catalog 
solution, including feasibility, functionality, performance, and cost. MnLINK requests that in each 
case vendors describe the degree to which such solutions: 



(1 ) meet the requirements of a single, centralized Union Catalog , 

(2) diverge from such requirements, and/or 

(3) present unique advantages not inherent in a single, centralized Union Catalog. 



However situated, the MnLINK Union Catalog must be capable of handling both full bibliographic 
records as well as provisional and/or brief records. In addition, the Union Catalog must provide 
capabilities which albw an individual library or group of libraries to include or exclude from the 
Union Catalog records of certain types, such as those for items on order, certain library specified 
sets of records including catalog subsets and/or those for MARC based local information and referral 
files. The MnLINK Union Catalog should provide the capability to assign a single record to several 
catalog subsets with independent control over whether various user types may search and display 
such catalog subsets. 
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Basic Union Catalog Search and Retrieval Capabilities 

The native search and retrieval capabilities of the MnLINK Union Catalog together as well as its 
associated Z39.50 Version 3 Server capabilities will provide the basis for receiving and responding 
to user inquiries initiated at an End-User workstation client via a MnLINK Z39.50 enabled Gateway. 

Via such a Gateway, the Union Catalog must support state of the art searching capabilities including 
exact phrase and keyword searches, Boolean combinations, proximity searches, browsing, and 
truncation, and other search mechanisms present in other large state of the art union catalog 
projects. The Union Catalog should be capable of providing access to any part of the bibliographic 
record including all MARC fields or parts of fields. 

Multi-item query results should be presented in an ordered display. The overall design of the Union 
Catalog and Gateway Systems should allow the designated System Administrator of a particular 
MnLINK Gateway to choose the default ordering of both multi item and single item displays and 
should albw an individual user to modify the ordering of such displays. 

Union Catalog Database Concept 

In concept, the MnLINK Union Catalog will contain bibliographic records from participating 
Minnesota libraries; users making inquiries of the Union Catalog must be able to determine holdings 
and availability information for each title in the Union Catalog in the most efficient way. Users of the 
Union Catalog should perceive that for a title of interest, the Union Catalog contains a single set of 
bibliographic records and detailed holdings, status, and availability information, whereas such 
information maybe stored centrally in the MnLINK LJnion Catalog or may be compiled on demand 
as a result from a Z39.50 inquiries of individual library OPACs. 

Proposers are invited to put forward the optimum arrangements to address these requirement. 
Proposers must assume that not all libraries will participate in a single MnLINK Shared System. 
Proposer must assume that some number of libraries in the state will continue to use one of a 
number of local automated library systems now in place throughout Minnesota. Although a number 
of libraries may elect to participate in a MnLINK Shared System, the MnLINK project is not intended 
to displace the investments of all libraries in Minnesota with a single vendor or system. 

If a vendor puts forward a solution in which a single, centralized Union Catalog maintains detailed 
holdings, status, and availability, feasible methods for maintaining the currency of this information 
also must be put forward. If a proposer recommends a single, centralized Union Catalog which 
does not maintain detailed holdings, status, and availability information that proposer must also 
describe methods for compiling such information on demand. If a proposer puts forward one or 
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more forms of a distributed Union Catalog that proposer must address methods which provide for 
the on demand compilation of union catalog type bibliographic, detailed holdings, status, and 
availability information from a number of local automated library systems using Z39.50 capability. 

The MnUNK Union Catalog must be scaleable and provide capacity for growth to accommodate full 
participation by a broad spectrum of Minnesota libraries of varying size and type and potentially 
multi-type networks of libraries. The Union Catalog must allow libraries, and campuses sharing a 
MnUNK Gateway, consistent with MnUNK policies and procedures, to customize the scope and 
reach of a user's search in a variety of ways including specifying which libraries, databases, and 
systems a particular search will address. The MnUNK Union Catalog must allow for the creation of 
specialized "virtual collections" of library selected material intended to support certain types of uses 
such as individual distance learning courses. 



A Centralized MnUNK Union Catalog 

Whether or not a proposer puts forward a single centralized MnUNK Union Catalog, the MnUNK 
Union Catalog must provide for initial MARC record loading from the initial set of individual library 
OPACs either via direct input or via vendor provided pre-processing. The MnUNK Union Catalog 
must not require MnUNK participant library staff to undertake any specialized processing of 
bibliographic and/or holdings information as output from local OPAC systems prior to input to the 
MnUNK Union Catalog. However, the Union Catalog should provide methods for individual 
participating MnUNK libraries to choose whether or not certain library identified classes of records 
should appear in the Union Catalog. 



A single, centralized Union Catalog also should utilize the master record concept, where Union 
Catalog input processing detects duplicate bibliographic records and combines bibliographic 
information into a single record based on choice of the highest quality cataloging source e.g., 
(Library of Congress Source as transcribed by the Library of Congress [e.g. DLC:DLC] as first 
choice, of cataloging source followed by hierarchy of cataloging source). Vendors are invited to 
propose arrangements for creating and maintaining a Union Catalog of high quality. Should a 
vendor propose a distributed Union Catalog, the vendor should indicate how the quality of such a 
distributed database would be established and maintained such that the MnUNK Union Catalog can 
retrieve all copies or forms of a work by a single author or pertaining to a specified subject without 
regard to where among the MnUNK participating libraries such material may be held. 



For a centralized Union Catalog duplicate detection should use a hierarchy of matching criteria 
including: matching OCLC # as first choice, matching ISBN with confirmation based on title words, 
matching ISSN with confirmation based on title words, and matching LCCN with confirmation based 
on title words. For the initial Union Catalog MnUNK recognizes that acceptable and reliable level of 
quality may require specialized input processing outside of the capability of the Union Catalog 
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System or Service itself. In a similar manner for purposes of serials, a Minnesota Union List of 
Serials record will be the master record in the MnLINK Union Catalog; in the establishment and 
update of the MnLINK Union Catalog database, a vendor must not overlay such serials master 
records with any locally generated local library serial records. The MnLINK Union Catalog must 
accommodate the Local Data Record (LDR) structure as used in the OCLC Union List record. 

MnLINK acknowledges that despite the methods in use to determine master record and identify 
duplicates, some library material will be inconsistently represented due to local cataloging practices. 
For example, some libraries have catalog records for government documents and some do not. 
Some libraries have fully analyzed major sets and series, and others have only a bibliographic record 
for the set or series as a whole. Therefore, some level of inconsistency and potential duplication will 
exist should MnLINK establish a centralized single Union Catalog; however, MnLINK requires that 
the proposer's Union Catalog System minimize such inconsistency and duplication and each 
proposer demonstrate its capabilities to minimize such problems. Vendors should project based on 
its experience the effect of either a centralized or distributed Union Catabg design upon such 
matters. 

Both initially and on an ongoing basis, the MnLINK Union Catalog must provide for authority type 
analysis and reporting related to subject and name headings for bibliographic records added to the 
Union Catabg. The MnLINK Union Catabg must provide reports for each new occurrence of a 
name, series, subject, and uniform title added entry, organized both by alphabetized entry and by 
library and/or campus and frequency. MnLINK intends this capability to provide an informal basis 
for monitoring the bibliographic input to the Union Catabg and the capabilities of the system itself to 
correctly identify duplicate records upon input. MnLINK will devise procedures for sampling from 
such reports to assure itself regarding the quality of the Lin ion Catabg on an ongoing basis. 

MnLINK seeks a LJnion Catabg vendor which will propose methods either for MnLINK or for the 
vendor to assume responsibility for maintenance of the MnLINK Union Catalog including the 
associated authority files and related access points. The vendor of Union Catalog systems/services 
will provide upon the establishment of the Union Catalog and on an ongoing basis Library of 
Congress MARC based authority records foreach and every access point for which such authority 
records exist, including any and all updating of MnLINK Union Catabg authority records based on 
newly released LC MARC authority data. Vendor costs for the Union Catalog must include 
maintenance of authority files and related access points. 



Updating A Single, Centralized MnLINK Union Catalog 



Whether the vendor proposes a centralized or distributed design for the Union Catabg, the vendor 
must demonstrate that MnLINK can manage the catabg on an ongoing basis. A single MnLINK 
Union Catalog must provide for continuous update via a variety of methods including batch 
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tape loading or online uploading from an authorized library and/or campus cataloging workstation. 

{ Some MnLINK libraries already have cataloging workstations which have capabilities for uploading 

cataloging to two sources, e.g. OCLC and their local OPAC system. By extension, such capabilities 
maymake it possible to update online the MnLINK Union Catalog automatically on an ongoing bass. 
Alternatively, batching of cataloging records for FTP to the Union Catalog among other destinations 
may present another alternative. The proposer must take into consideration in recommending a 
solution the requirement that updating the MnLINK Union Catalog impose as little as possible on the 
ongoing operations of the cataloging departments of MnLINK participating Libraries. 

The MnLINK Union Catalog system must support complete authority control, including the capability 
for linking records in and between files, validating and verifying headings, "deblinding" cross 
references, processing global changes, and other required maintenance. The MnLINK Union 
Catalog System must be capable of deriving authority data from machine-readable bibliographic 
records and of accepting batch input of authority data from such sources as LC, OCLC, RLG, NLM. 
BNA, and Brodartor any other source. The authority control subsystem must also accommodate 

juvenile subject headings. 

The MnLINK Union Catalog must provide for downloading of a Union Catalog based cataloging (e.g. 
MARC) record upon the request of a MnLINK library operator. The MnLINK Union Catalog must 
§1 provide an operator with proper authorization the ability to update records online as an editing 

function to correct obvious errors and problems which do not admit of any other solution. The 
vendor's system must provide MnLINK with such a capability. 



Distributed Union Catalog 

Earlier sections enumerate aspects of creating and maintaining a single, centralized Union Catalog. In 
a distributed or "virtual" union catalog such matters may not arise directly. MnLINK requests that 
vendors comment on the degree to which a vendor proposed distributed union catalog design 
meets the objectives of a physical union catalog. 



A distributed union catalog approach must: 
















demonstrate the ability to work within demonstrably reasonable network bandwidth 
requirements, 

work together and conduct search and retrieval operations with local automated library 
systems of different design and manufacture than that of the Union Catalog server. 



xecute broadcast searches against an arbitrary number of local automated library system 
ervers within a reasonable amount of lime without excluding results from one or a 
ignificant number of servers, 



achieve search and retrieval results comparable 
Catalog in an environment in which local servers 
differences in record completeness or quality, and 



to those of a single, centraTized Union 
and databases exhibit subtle or profound 



ERiC 



124 



Page: A 70-76 



MG Consultants, Inc. February 3,1997 . ef p M n Consultants ha 

7 his proprietary RFP version 2.01 * copyrighted; it may not be copied or distributed without the express writen consent of RMG Consultants, ha 



RMG Consultants. Inc. 

MnLINK 






1 1 .c>j run 



LJ i 



MnLINK REQUEST FOR PROPOSAL 



either must possess sophisticated abilities to detect and process duplicate records in real 
time or impose that task upon the end user. 



Notwithstanding such constraints and requirements, advocates for distributed or virtual union 
catalogs and for so-called "broadcast" or "parallel" searching have advanced strong arguments for 
such approaches in recent years. MnLINK seeks to establish the viability of either or both the 
single, centralized union catalog or the distributed "virtual" catalog in its setting. MnLINK requests 
that proposers respond to either or both approaches to a MnLINK Union Catalog and characterize 
the feasibility of each approach for MnLINK. 

Union Catalog Server Capabilities 

The Union Catalog server capabilities are intended to consist of a set of system -oriented query-only 
functions for search and retrieval of records contained in the Union Catalog via a Z39.50 Version 3 
or later interface. Such capabilities must exist whether the Union Catalog is centralized or 
distributed. The Union Catalog ultimately will rely upon Z39.50 as a protocol for the transport of 
search requests and search results. As such the Z39.50 Server capabilities of the Union Catalog 
effectively will mediate the Union Catalog's search capabilities to the end-user. Among the local 
systems in place in Minnesota and among both local library systems and other Z39.50 servers, 
capabilities of the underlying search engines in place vary. These differences work to constrain the 
searching capability which an end-user can obtain from any particular server or group of servers. 
However, for MnLINK, the implementation of a Gateway System is intended to provide a consistent 
and coherent search environment spanning all MnLINK libraries and campuses, despite the variety 
of local system choices at the individual library level. Therefore, MnLINK will examine carefully the 
abilities of the Union Catalog for search and retrieval and the ability of the selected MnLINK Gateway 
to interoperate with the MnLINK Union Catalog. Vendors are required to demonstrate (1 ) 
compliance with NISO Z39.50 Version 3 and (2) interoperability with a wide variety of Z39.;50 
clients at a detailed feature by feature level. 

The Union Catalog and Z39.50 Server capabilities should be flexible to allow for adaptation by 
MnLINK. The Union Catalog and Z39.50 Server should have the ability to search across all library- 
specified MARC fields, material formats, and all other MnLINK library data. 

The Union Catalog and Z39.50 Server should provide for keyword typed in as a phrase, in that 
exact order (implicit; "and" implied). The combined Union Catalog/Z39.50 Server should allow the 
searcher to combine terms with Boolean AND, OR, and NOT operators (explicit) and to make 
efficient use of such Boolean operators in conducting searches. 

The Union Catalog/Z39.50 Server should allow the searcher to limit searches by library-specified 
fields, including fixed fields and specific material formats, either before or after the search is executed 

for the first time. 
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The Union Catalog/Z39.50 Server should accept the input of entire headings, even if they are long 
and subdivided. 

The Union Catalog/Z39.50 Server should allow when available proximity searching using the 
operators "near" and "within" and relational searching, using terms such as less than "<" or greater 
than ">". In general, the Union Catalog/Z39.50 Server should be browsable by call number and 
alphabetically by author, title, subject, and keyword. 

The authority control capabilities of the Union Catalog should be inherent in the Union Catalog and 
able to be utilized in searching via the Z39.50 Server. When a user enters any form of a name, title, 
or subject in a search, all bibliographic terns associated with that form should be retrieved, 
regardless of whatever name the author may have used or whatever variant form may have been 
chosen. The Union Catalog and the Z39.50 Server should accommodate the use of MARC authority 
records for all types of headings. 

Searches of the Union Catalog must permit the use upper or lower case letters and the absence or 
presence of spaces and punctuation marks. 

The Union Catalog and the Z39.50 Server should respond to a term not found by replying a list of 
terms preceding and following the entered term. The Union Catalog/Z39.50 Server may suggest 
keyword searching when an exact match search fails. 

If the Union Catalog/Z39.50 Server requires the use of any stop-words, the library must be able to 
choose which stop-words to use. If the patron's search results in zero hits because a - interfered, 
an informative message should explain the problem. 

The Union Catalog/Z39.50 Server should permit as standardized character masking (wom*n 
retrieves both women and woman). 

The Union Catalog/Z39.50 Server search capabilities should minimize the practice of vendor specific 
private extensions to the standard Z39.50 protocol, should publicly register for open use any such 
private extensions, and should migrate to the use of public and commonly recognized 
implementations of various search and retrieval protocol elements as soon as such approaches gam 
recognition and are suitable for implementation. 



BEST COPY AVAILABLE 

126 




7 his proprietary RfP version 2*01 is copyrighted; it may' 



February 3, 1997 pa R e: A 

not be copied or distributed without the express written consent of PMC Consuktnts. he. 



February 3, 1997 



RMG Consultants. Inc. 

MnUNK 






vy i i i rm 



MnUNK REQUEST FOR PROPOSAL 



7.4 MNUNK GA TEW A Y SERVER AND THE SEARCH AND RETRIEVAL CLIENT 

The MnUNK Gateway Server presents the End-User Client Workstation with a single interface 
available across a variety of desktop and mobile computing platforms. Although the MnUNK 
Gateway server exists exclusively for the benefit of MnUNK's End-Users as opposed to library 
staff, the vendor must provide MnUNK with assurance that its Shared System can support, in a 
sim ilar manner, a variety of desktop and mobile computing platforms, including Windows (Windows 
3.11, Windows 95, and Windows NT), Unix, and MacOS operating systems. The vendor must 
provide a mechanism which eliminates the need for library staff uses of the Shared System to gain 
access to that system via the MnUNK Gateway Server(s). 

The MnUNK Gateway Server enables a user at such a workstation to gain access to a wide variety 
of databases, applications, systems, and services. The MnUNK Gateway Server provides access to 
resources such as: the MnUNK Union Catalog, detailed holdings inform ation, status and availability 
information about individual terns of library material from local MnUNK participating OPACs, an 
index and/or catalog of Internet resources, subscription and pay-per-view databases, interlibrary 
loan, and commercial document delivery. 

The MnUNK Gateway Server operates as locally as possible, potentially from each library and/or 
campus in a TCP/IP Internet communications environment, communicating with the End-User Client 
Workstation via HTTP/HTML communications and presentation protocols. The Gateway Server 
shall support HTML Forms, CGI scripts, PERL, and secure transmissions. Although intended to 
support such HTML based graphical clients such as Netscape, Mosaic, and Internet Explorer, it 
must also support the ASCII client Lynx. Although support of Lynx does not represent a primary 
function of the Gateway, MnLINK requires such a capability both for Americans with Disabilities Ad 
(ADA) compliance and for limited backward capability with the large population of terminal devices 
for which libraries and institutions are developing replacement schedules. 

The MnLINK Gateway Server should communicate with remote databases, systems, and services 
via open systems based protocols, agents, and search engines appropriate to function being 
performed. MnUNK requires the provision of Z39..50 Vers bn 3 capability for searching the 
MnLINK Union Catalog, individual participating MnLINK online public access catalogs, other non 
MnLINK library catalogs, licensed subscription databases, and pay-per-view databases. Moreover, 
MnLINK requires demonstrated ability to interface and to interoperate successfully with other 
vendors' Z39.50 Servers. MnLINK considers that the provision of additional capabilities (such as 
access to SQL databases, Verity Topic™ agent technology, Web search protocols and search engine 
access, etc.) as they extend appropriately the reach of the MnLINK system will add value to a 
vendor's overall proposal. However, such technology must demonstrate actual operational value 
for MnLINK and not just technobgical capability. 
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The Gateway Server software must operate on industry standard hardware and operating system 
software such as Unix or Windows NT. MnLINK recognizes that the marketplace currently is 
arguing the preferences each of these two operating systems. The ability to configure the Gateway 
Server on various operating system platforms and in configurations of varying capabilities and cost 
may add value to a vendor's proposal, if all other factors remain equal. MnLINK Gateway Server 
software, including all components should be programmed in standardized high level languages such 

as C or C++. 

Individual users shall have the ability to gain access to the MnLINK Gateway Server from any point 
at which a TCP/IP Internet or MnLINK LAN/WAN network connection may be made, including direct 
connections from a participating MnLINK Library, various desktops connected to a library and/or 
campus network or the MnLINK LAN/WAN network environment, other desktops connected to the 
Internet, as well as SLIP or PPP dial-up locations. Except for connection speed, the MnLINK 
Gateway Server interface shall function identically for the user from anywhere it is accessed. 

The Gateway System should allow the searcher to exploit fully the searching capabilities of the 
MnLINK selected Union Catalog/Z39.50 Server configuration. The Gateway System should allow 

users to: 

limit searches by library-specified fields, either before or after the search is executed for the 
first time. 

limit each search to a specific participating MnLINK library location, search a subset of 
MnLINK library locations, or search the entire Union Catalog database. 

receive notification if a bng search is in progress and given the means to interrupt such a 
search. 

save a search (or searches) and combine the results with subsequent search results lor, 
these should be automatically saved and assigned numbers to combine with subsequent 
searches)]; such search history should be maintained until the workstation is returned to 
the beginning screen through time-out or intentional exit. 

display the number of titles which contain the tern in question, when a search results in a 
match against an item. 

The Gateway System should have the ability to retrieve holding location, status, and availability 
information for bibliographic records of materials catabged, on-order, in-process, or partially 
converted to machine-readable form. 

The Gateway System must project a flexible patron interface. The library or libraries sharing a 
Gateway should be able to choose the type of opening screen - tutorial or an invitatbn to begin 
searching - and the content of the messages. In general, the retrieval of inform atbn from the 
database must be accompanied by clear, concise instruction displays which can be edited and 
formatted by the library. The Gateway System should avoid library or computer jargon, using as 
much natural language as possible. The user must be given the option of choosing a mode of 
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interaction consistent with skill level (i.e., novice vs. experienced user). Online assistance should be 
provided to the extent necessary to guide a user logically and efficiently through the search process 
using natural language as much as possible. The means of getting to help screens should always be 
visible be spelled out, graphically clear, or mnemonic (H for Help). A path to HELP facilities should be 
available as should a list of available options at any point. A conventional set of such options (e.g. 
Start Over, etc. must persist throughout the user session). Context specific help should always be 
available. Local adaptation, particularly the ability to alter the content of help facilities, should be 

possible. 

How-to-start over instructions or buttons should ajwajys be visible, not just on the opening screen. 
The means of getting out of someone else's search should always be evident, and simple. A time-out 
should be implemented at the Gateway Server level. However, the user should have the ability to 
resume an existing search at any time. 

Patrons should not to be able purposely or accidentally to exit, freeze, or disrupt normal operation 
of the system. 

Session Management 

While basic HTTP/HTML transactions are stateless, the MnLINK Gateway System will support virtual 
usersessions for the purpose of user authentication / authorization, and search request status and 
history. Such sessions will generally be supported by a method such as passing a token between 
the HTTP/HTML End-User client and the MnLINK Gateway System. Session capabilities should 
include: authentication, authorization, search history, and search progress reporting. 



Authe ntication 

The MnLINK Gateway Server component identifies and provides MnLINK network authentication 
and authorization of MnLINK users. Vendors are requested to provide information regarding their 
capabilities to register patrons with more than one library affiliation. Does the vendor's system have 
the capability to aggregate a patron's privilege sets in an intelligent manner? How does the vendor's 
system record usage statistics for such patrons? 

User identification should consist a unique number or alphanumeric string which differentiates an 
individual from all other individuals using MnLINK systems and services. This method of 
identification functions similarly to an e-mail login name or a library patron identification number on a 

borrower card. 
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Authentication consists of a procedure for confirming that the identification presented by an 
individual is valid; usually authentication consists in challenging the user to verify their identity by 
presenting a second form of identification, usually in the form of a word or number assigned to the 
individual in question and which should be known only to that individual and the system presenting 

the challenge. 

The MnLINK Gateway albws System Administrators to require user identification and authentication 
in order to restrict access to some systems and services (e.g. licensed databases) to recognized 
members of a group entitled to such access. User authorization consists in the process of 
determining the ability of an identified and authenticated user to gain access to specialized resources 
beyond those defined for the user group or class of which the individual is a member (e.g. library 
patron, library staff, etc.). User type represents one type of authorization. Library staff and library 
patrons may have access to different systems and services solely based upon such a status. In 
another case, authorization may consist in the system determined ability of the individual to assume 
responsibility for financial obligations associated with a pay-per-use database. The MnLINK 
Gateway must have the capabilities to handle the most obvious types of authorization and to 
incorporate new authorization techniques as required. 

A single point of authentication and authorization permits users - e.g., registered patrons (wherever 
such users may gain access to MnLINK - the local library and/or campus, the MnLINK LAN/WAN 
network environment, or via the Internet) to make permitted uses of any and all local and remote 
services (including pay per view account authorization). The authentication and authorization 
services should allow MnLINK via designated System Administrators to script the conditions for 
which such an authentication process must take place and to change such scripting as policies 
governing various systems, services, and resources change. For example, such authentication / 
authorization might occur at the point at which such users make interlibrary loan requests, or 
attempt to gain access to any digital or library resources deemed to require secured or restricted 

access. 

The MnLINK Gateway System should request authentication from users only as necessary. In 
many cases the Gateway System should recognize the user via a MnLINK library and/or campus IP 
address; in some cases in which such IP authentication is not possible, the Gateway System should 
require identification via a valid password or Personal Identification Number (PIN). For example, in 
general, a student in a lab on a campus should not have to go through an authentication process for 
use of the local OPAC, the Union Catabg, or other MnLINK pre-paid information resources. 

Use of existing PIN or passwords already established for MnLINK library patrons is viewed as an 
absolute requirement. The MnLINK Gateway System must determine the validity of a user from a 
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database created and maintained either via automatic methods or a specialized MnLINK registration 
process. Automatic input could occur in real time or batch and could derive information from an 
interface with library and/or campus registration, e-mail account files or library borrower files. 

Beyond authentication some MnLINK services may require specific authorization in order for users 
to gain access. Authorization maybe based on any of a number of conditions, including: borrower 
category information of any type. The MnLINK Gateway System must allow MnLINK via designated 
System Administrators to put in place authorization, at MnLINK's option, for resource intensive 
functions, such as searching of multiple databases in parallel (broadcast search). For other services 
such as pay per view databases, authorization will depend upon ability and willingness to "pay" for 
service. The MnLINK Gateway System may require a user to have permission to draw upon a 
minimum free balance in an established deposit account or willingness and ability to make immediate 
payment via some form of credit instrument (e.g. credit card, smart card, etc.). 

A user should be able to save a search and target a separate database or databases or modify a 
search and resubmit it against the same database. The MnLINK Gateway System should provide for 
this capability by logging the interaction between the user and application clients such as Z39.50 
enabled MnLINK Search and Retrieval or other "Client" processes. The MnLINK Gateway System 
should support for authorized users the ability to store designated searches between search 
sessions. 

The MnLINK Gateway System should albw session management capabilities such that the Search 
and Retrieval Client can report on its own status to the end user via the Gateway Server. Such 
session management capability should allow monitoring of the state of a search in progress as well 
as the state of the user as the user shifts contexts from viewing data to operating on data, such as 
requesting interlibrary loan or document delivery of a particular title. 



Search Capabilities 

The basic search methods of the MnLINK Gateway System will require Z39.50 Version 3.0 or later 
protocols on target servers, including local library systems in order to gain access to the content of 
such servers for MARC record and other types of searches. The MnLINK Gateway System must 
also have capabilities for alternate search protocols such as local or remote submission of a user's 
search input to a Web Server search engine via HTTP Forms capability. The MnLINK Gateway 
System must have the capability to submit a user search to either a Z39.50 Server, a Web Server, or 
both in parallel. The MnLINK Gateway System must search multiple target databases on different 
servers with one "broadcast search". If the proposed Gateway system can search using various 
protocols, agents, and search engines, it must have effective methods to resolve the results returned 
( via various methods and servers into an intelligent display for the end-user. 
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The MnUNK Gateway System must use the state of the art Z39.50 Vers ion 3.0 information retrieval 
protocol and advance that protocol where necessary to incorporate new and wanted search 
capabilities. When searching MARC record databases, the MnUNK Gateway System must present a 
simple default search logic. In addition, the user must have the ability to customize when formulating 
complex search strategies upon request. When the MnUNK Gateway System interacts with Z39.50 
Version 3.0 servers it must have the ability to effect advanced searching strategies such as Boolean 
searches, adjacency searches and limiting by format or location. 

Ultimately the MnUNK Gateway System depends upon the search capabilities inherent in each target 
server, their implementation, and the ability to invoke these capabilities via Z39.50. The MnUNK 
Z39.50 Client Component must have the ability to utilize fully the capabilities and services of a wide 
variety of Z39.50 Servers of various types and manufacture, despite differences in server hardware 
and software design and protocol implementation. Vendors must demonstrate the capability of their 
solution to achieve this end by interoperability at a detailed feature by feature level with the Z39.50 
Servers of other vendors. 

Therefore, although MnUNK may not impose search requirements, in practice, on systems beyond 
the MnUNK Union Catalog, the MnUNK Gateway System should present no obstacles to the 
formation of both simple searches and more complex searches according to the capabilities of the 

MnUNK Union Catalog. 

The MnUNK Gateway System should be capable of retrieving and displaying kern status and 
availability from either a single, centralized Union Catalog, a Union Catalog supplemented by OPACs 
of libraries owning a particular item or kerns of interest, or a group of MnUNK Shared System and/or 
OPAC servers functioning as a "virtual" union catalog.. For the MnUNK Union Catalog the MnUNK 
Gateway System should also show item status, based on its ability to obtain such information either 
from the Union Catalog or from one or more local library OPACs via Z39.50 inquiry for the kern or 
kerns selected by a user. The MnUNK Gateway System should have default search profiles which 
define one or more groups of target Z39.50 Servers against which to inquire on behalf of the user. 
Authorized MnUNK staff must have the capability to modify such scripts and the end user must 
have the capability to compose a custom group of target servers against which to search. 

The MnUNK Gateway System must provide for smooth interaction with Z39.50 Servers for which 
MnUNK has made arrangements for use; the process of user identification, authentication, and 
authorization via login and password must appear as transparent as possible to the user and must 
function automatically without user interaction with external Z39.50 Servers wherever possible. The 
MnUNK Gateway System should report the progress of the search at the End-User Client (e.g. how 
~ many sites are done, how many remaining sites, percentage, etc) and the MnUNK Gateway System 

should allow the user to stop a search in progress with the results yielded so far available for 

display upon request. 
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The MnUNK Gateway System should albw a user to enter a single search query which the MnUNK 
Gateway System uses as the basis for searching several Z39.50 databases and other supported 
search interfaces at one time in a "broadcast search" of multiple target servers. The MnUNK 
Gateway System s hould allow the user to choose the default profile of target servers or to construct 
a custom list of servers. The MnUNK Gateway System should provide scripting capabilities for 
profiling multiple search interface designs. A search profile consists of a set of HTML formatted 
"pages" which form the background for search input, the display of results, and help screens; the 
profile also defines set of servers against which that search profile runs. 

The Gateway Server must albw an individual participating MnUNK library to define the scope of a 
user's search to include entire non-MnLINK collectbns by albwing profiled portions of the Z39.SO 
compliant catalogs of such libraries to be added to a MnUNK Gateway Server search. 

Display of Results 

The MnUNK Gateway System must make the display of search results meaningful and lucid, 
especially given the wide spectrum of servers, databases, and content in general that MnUNK 
searches may span. The MnUNK Gateway System must albw for intelligent ordering, filtering, 
formatting, and overall presentation of results from both single server and multiple server broadcast 
searches. 

The MnUNK Gateway System should albw for the display of search results in several types of 
order: alphabetically by search field(s), reverse chronological order, degree of term adjacency, or 
ranking by degree of fit with user's search criteria. The MnUNK Gateway System should albw 
default and user selected optbns for order of display by database and type of database, such as 
biblbgraphic, full text etc. The MnLINK Gateway System should allow for the filtering of a search 
either by a readily understood ranking scheme or according to pre-established criteria, such as 
subject area, date intervals, source (catalog, index, etc.). In any circumstance in which the MnUNK 
Gateway System utilizes a system assigned ranking the basis of that ranking should be evident to the 
user. 

When search results are returned from multiple databases a default or user specified display order 
should apply. The MnUNK Gateway System should albw display by database, or by a single 
sequence in cases where duplicates have been eliminated. 

Accessing Traditional Library Material and Digital Content 

The MnLINK Gateway System needs to make user choices for content access clear when it displays 
search results and when the user initiates a process for MnLINK interlibrary loan, or document 
delivery. In any display (such as that of Union Catalog records, index and abstract records), the 
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MnLINK Gateway System needs to make clear the available alternatives for access to that material* 
immediate linkage to the display of full text, chart, graphic image, video, audio, etc.; MnLINK 
interlibrary loan, or commercial document delivery. 



To the greatest degree possible, search results 
which the system and the user have determined 



should include the option to access the materials 
as relevant to the user's needs. For digital materials 



of interest, the user may select a clearly indicated link in the display. Supported links should include 
the 856 fields in MARC records. Choosing a link may lead to several results: 



Selecting the link should result in the direct retrieval of networked full text items, images, 
charts, graphs, etc. for display in the MnLINK End-User Client. 

Allowing the end userto request access to traditional library materials by document delivery 
or MnLINK interlibrary loan. 



For those instances in which a user requests MnLINK interlibrary loan, or commercial document 
delivery, the Gateway System should initiate a search of the library collection associated with the 
user first and display any titles which the MnLINK Gateway System believes might satisfy the 
request exactly. The MnLINK Gateway System via an interaction with the user should determine 
whether a user's interlibrary loan request remains necessary or valid subsequent to the review of 
the display of available material at the user's library and/or campus. If the user is not bcated at a 
MnUNK library and/or campus, the MnLINK Gateway System should search all MnLINK library 
and/or campus collections for exact or cbse matches to the user's requested tern and conduct a 
similar interaction with the user. Interlibrary Loan capabilities should support national standards 
including ANSI/NISO Z39.63-1 989 and subsequent revisions and ISO Interlibrary Loan Standard 

Protocols 10160/10161- 

The display or playback of some files will require multimedia abilities, including mage, sound and 
video display and playing. The MnLINK End-User Client should provide these capabilities via in-line 
and helper applications such as an MPEG player. 

The MnLINK Gateway System should provide options for pay per view searching. In such cases 
the MnLINK Gateway System should secure automatic charging of a user's credit card or debit 
account or withdraw funds from a library funded deposit. 



( 



BEST COPY AVAILABLE 



134 



o 

[RJC '.MG Consultants, Inc. February 3, 1997 

MHiaffffl il H 7^0 p r opriettry RFP version 2.01 is copyrighted: k mev not be copied or distributed without the express 



Page: A 10-26 

written consent of RMC Consultants , he. 



RMG Consultants. Inc. 



V 



MnLINK 



(812/3/97 ©11:14PM LJ7/S3 

MnUNK REQUEST FOR PROPOSAL 



7.5 INTERLIBRARY LOAN CLIENT 

The MnUNK Interlibrary Loan Client, located on the MnUNK Gateway System, works together with 
external Interlibrary Loan "server" systems to effect the loan of library material to end-users. The 
MnLINK Interlibrary Loan Client must work with any and all national, international, and industry 
standards for Interlibrary Loan as such standards are implemented within the library and information 
services industry; in particular, the ILL Client must work with such ILL systems as OCLC's 
Interlibrary Loan System, RLG, and NLM Docline. The MnLINK ILL Client System must support both 
direct patron initiated and library mediated interlibrary loan requests. 

As in all sections what this section describes represents an optimum system from the viewpoint of 
MnLINK; MnLINK understands that a vendor's system may fulfill the functionality called out in this 
section in more basic ways than those described herein; however, the ability to fulfill these 
requirements in a non proprietary framework is very important to MnLINK. 

End-User Authorization 




The ILL Client System must determine at the outset of an interaction with an end-user, if the user in 
question has authorization for inter-library loan transactions. The MnLINK Gateway System 
authentication /authorization system should allow MnLINK to profile which types of users have 
such authorization. This determination may depend upon information in the MnLINK Gateway 
System authorization system or it may require access to a patron file maintained by one of the 
participating MnLINK libraries. 

MnLINK requires that individual libraries be able to set different thresholds for each type of 
interlibrary loan transaction. MnLINK requires the ability to enable or disable ILL capability for 
various types of end-users as a group (e.g., library staff, patrons, etc.); MnLINK also requires the 
ability to modify such end-user profiles by end-user type easily. MnLINK seeks to block end-users 
from requesting ILL transactions when they have defined levels of overdue fines or other charges 
pending in their records. In addition the ILL Client System must albw MnLINK to limit the number of 
ILL transactions which any patron may have outstanding at one time or over a MnLINK prescribed 
interval of time. The ILL Client must provide MnLINK with the capability optionally to limit the 
number of ILL transactions to any one end-user without cost, to impose costs upon an end-user 
beyond such thresholds for ILL service, and to verify during the authorization process that an end- 
user has the ability to pay for such costs (e.g. a deposit account or a debit card). 
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The ILL Client should provide each library and/or campus with the option of providing delivery of 
inter-library and/or campus circulation material to a non library and/or campus ^address. The ILL 
Client should also permit the imposition of costs for value added services, such as a charge for 
direct delivery to locations (such as a home address) not served by the existing MnUNK inter- 
library delivery service. 

If an end-user is authorized for inter-library and/or campus circulation, the ILL Software Client must 
obtain from the MnLINK Gateway System authorizatbn system or the appropriate local system 
patron file sufficient information to albw the library which fulfills the request to directly charge the 
material to the patron in question. Such information should include name, patron identification 
number, current telephone number, home address, and e-mail address from the end-user making an 
inter-library and/or campus circulation request, so that information on the progress of the inter- 
library and/or campus circulation (e.g. fulfilled, not fulfilled, etc) may be sent via this method. 

Material Availability 

The ILL Client will use Z39.50 searches of one or more holding libraries to determine detailed 
holdings and availability of the item or items in question. Before albwing an MnLINK end-user to 
effect inter-library loan, the ILL must determine whether or not the end-user's home library holds the 
item in question and whether the item is available at that location. The ILL utilizes the 
authentication/authorization capabilities of the MnUNK to determine the home library and/or 
campus. The end-user's seledbn of an item and a request for interlibrary ban of that item signal the 
ILL that it should make such a determinatbn. If the ILL determines that the end-user can obtain the 
item from the home library, the II I refers the end-user to that library. The ILL should provide the 
capability for a user with special authorization (end-user or library staff) to request an ILL 
transaction, even if the home library holds an available copy of the wanted item. 

The ILL System must provide a means for individual MnLINK libraries, at their option, to specify that 
subsets of the collectbn or the entire collectbn may circulate locally, but will not circulate as a part 
of the ILL capability. For example, course reserve material should not circulate beyond outside a 
library. 

The ILL Client System must provide a method which can assist in equalizing demand upon MnLINK 
tending libraries. Methods may vary, but could range from informing users of the queue of ILL 
transactions which each library is currently processing to very formalized load balancing algorithms 
which dictate the localbn from which an end-user may make an ILL loan based on current ILL 
workload and workload over some MnLINK established intervaL 
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Transaction Processing and Transfer of Material and Record Keeping 



The ILL System must capture all information necessary regarding patron and item for the recipient 
MnLINK library to effect a circulation transaction, should staff find the tern in question on the shelf. 
Such information should include the name, address, telephone number, and patron identification 
number of the end-user, the local call number and shelf location of the item to be borrowed from the 
participating Library's local catalog as a part of the transfer of an interlibrary loan request The ILL 
Client should transfer online requests for interlibrary loan to the library selected as the potential 
provider of the material. 



The ILL System must support a mechanism for staff at the named potential lending library to call up 
ILL requests and dispose of such requests based on whether the material is in fact available. For 
requests which it can fill, staff of the lending library must have the capability to inform the requesting 
library and patron of the inter-library loan at an e-mail or an alternate form of address. In the event 
that the designated library can not fill the ILL request the ILL System must provide the ability to refer 
the request to another MnLINK library (should the originating library so stipulate), to refer the 
request to the originating patron's library, or to generate an external interlibrary loan request. In 
order to refer the lending request to another MnLINK library, staff at that library must have the 
ability to call up the request, search the MnLINK Union Catalog for other libraries with available 
holdings of the title in question, and refer the request to an appropriate library. The ILL System 
should also albw either the library receiving an ILL requestor the library of the patron making an ILL 
request to use the ILL request as the basis of an external Interlibrary Loan request. The ILL System 
should require the library receiving an ILL request to inform the requesting patron and the patron's 
library of the disposition of the request. This capability will albw unfilled requests to proceed to the 
next potential lender without the need to return to the originating library or patron to identify 
another potential lender among MnLINK Libraries. 

The ILL System must support tracking of interlibrary loan transactions. The ILL System should not 
require any additional library record keeping to monitor transactions from origin to the fulfillment of 
the request or to produce management reports. The ILL System must provide MnLINK Libraries the 
capability for billing back the requesting patron or the patron's library; alternatively the system must 
provide for an accounting of credits and debits for net lending and net borrowing among MnLINK 
Libraries similar to OCLC's Loan Reimbursement System. Once MnLINK ILL Client has placed an 
interlibrary loan request the tracking and processing of the loan request becomes the responsibility 
of the ILL server (e.g. the ILL server on the MnLINK Shared System). Should the capability exist for 
interaction between the server and the MnLINK ILL Client, the ability to report the disposition of the 
ILL request at various stages of processing by the ILL server would be highly regarded. However, 
proposers should recognize that any additional work imposed upon MnLINK library staff to 
coordinate between various ILL systems and MnLINK ILL client would not be viewed favorably. 
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7.6 DOCUMENT DELIVERY APPLICA TION CLIENT 

/* 

( ; 

The MnLINK Document Delivery Client, located on the MnLINK Gateway System, works together 
with external Document Delivery "server" systems to effect the delivery of wanted information to 
end-users. The MnLINK Document Delivery Client must work with any and all sources of 
document delivery services. MnLINK encourages proposers to work together with document 
delivery services and national and international standards bodies to define and implement a service 
definition and standard protocol for document delivery covering the process from request to 
fulfillment The MnLINK ILL Client System must support both direct patron initiated and library 
mediated document delivery requests. 

End-User Authorization 





The Document Delivery Client System must determine at the outset of an interaction with an end- 
user, if the user in question has authorization for such transactions. The MnLINK Gateway System 
authentication /authorization system should allow MnLINK to profile which types of users have 
such authorization. This determination may depend upon information in the MnLINK Gateway 
System authorization system or it may require access to a patron file maintained by one of the 
MnLINK libraries. 

Although the requirements for end-user authorization for Document Delivery turn on the same 
criteria as those for inter-library and/or campus circulation and interlibrary loan, MnLINK requires 
that MnLINK and individual libraries and campuses be able to set different thresholds for each type 
of transaction. MnLINK requires the ability to enable or disable Document Delivery capability for 
various types of end-users (e.g. 1st year students, staff, library staff, faculty); MnLINK also requires 
the ability to modify such end-user profiles by end-user type easily. MnLINK seeks to block end- 
users from requesting Document Delivery transactions when they have defined levels of overdue 
fines or other charges pending in their records. 

The Document Delivery Client must provide MnLINK, and MnLINK Gateway System Administrators 
with the capability optionally to limit the number of Document Delivery transactions to any one end- 
user without cost (including zero [0]), to impose costs upon an end-user beyond such thresholds 
for Document Delivery service, and to verify during the authorization process that an end-user has 
thd ability to pay for such costs (e.g. a deposit account or a debit card). 

If a end-user is authorized for document delivery service, the Document Delivery Client must obtain 
from the MnLINK Gateway System authorization system or the appropriate local system patron file 
sufficient information to complete an delivery transaction with an external Document Delivery 
server, such as name, patron identifier, a current telephone number, home address, e-mail address, 
and mode of document delivery: physical address, fax, e-maiL regular mail, express mail, etc. 
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Material Availability 

The Document Delivery Client must use Z39.50 searches of the MnLINK Union Catalog and other 
catalogs of libraries with whom MnLINK has working resource sharing agreements to determine 
whether the item in question maybe obtained via inter-library and/or campus circulation, interlibrary 
loan, or other method of non-commercial document delivery In particular, before allowing an 
MnLINK end-user to effect a document delivery transaction, the Document Delivery Client must 
determine whether or not the end-user's home library holds the item in question and whether the 
item is available at that location. Document Delivery utilizes the authentication/authorization 
capabilities of the MnLINK to determine the home library and/or campus. A document delivery 
request begins with the input of the bibliographic information which the user has for the item in 
question and a search of the databases available to the user via the MnLINK.' For an authorized 
user type, failure to find the item should result in a request by the system for additional search input 
of specified types: author, title, and other information which could improve the user's chance of 
identifying the wanted item from the MnLINK Union Catalog and other catalogs available for 
searching based upon the user's MnLINK profile. If such an augmented search does not locate the 
wanted fcem and the user meets the MnLINK and library and/or campus criteria for such service, the 
MnLINK should offer the user the option of initiating a request for document delivery service. 

Transaction Processing and Transfer of Material and Record Keeping 

Once the MnLINK has initiated a document delivery request the tracking and processing of the 
request becomes the responsibility of the external Document Delivery server. Should the capability 
exist for interaction between the server and the MnLINK Document Delivery Client for reporting on 
the disposition of the Document Delivery request at various stages of processing by the external 
system, such a capability would be highly regarded. However, proposers should recognize that 
any additional work imposed upon MnLINK library staff to coordinate between various external 
systems and MnLINK Document Delivery Client would not be viewed favorably. 
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7.7 MAN A CEMENT INFORMA TK)N SYS TEM/REPOR T GENERA TOR 

(■ 

The Management Information System is intended to provide detailed summaries of data on the 
operations, use, activity, and performance of the system overall and each system in particular. 

Such information is required by MnLINK to monitor use of the system, to determine resource 
allocation and costs of various subsystems, and to plan for system utilization and expansion. 




A Report Generator facility is needed to generate customized reports from user-designated files and 
combinations of files, according to user-specified parameters for the contents and formats of 
reports. This module is intended for use by library staff to generate ad hoc reports from the 
database, and select and output wanted records. 

This module should be easy to use and allow for retrieval of records from one or more files, 
according to the presence of specified fields and/or specified values in those fields. 

Custom report generation capabilities should include the on-demand production of reports based on 
data from across all system files and records. Authorized users should be able to customize formats 
of reports, including use of various print styles and sizes. The custom report generator must be 
easy to use, without requiring knowledge of programming languages. Descriptions of the use and 
capabilities of the custom report generator, as well as samples of custom reports, should be included 
with proposals. 
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Attachment C Library Planning Task Force DRAFT 1 1/2S/96J 

Minnesota Library Information Network 





GOVERNING BOARD 
Membership: Library Planning Task Force 
(for July ,97 to June, 99 biennium ) 


OPERATIONS COUNCIL 
Members: IS maximum 
MILS User Representatives 
Interconnectivity Users 
Non-voting ex-officio Reps: 
Governing Board 
MINITEX, LDS, 
Telecom. Council 


Responsibilities: 

Establish policies and set standards for MnLIN 
Plan for the continued development of MnLIN. 
Oversee fiscal operations including: 

Seek and receive funding from governmental, 
private, and participant sources. 

Approve the MnLIN budget and 
fee structures for participants 
Contract for administrative and operational services 


Responsibilities: 

Oversee and operate MnLIN 
within die policies, standards, and 
budget set by Gov. Board. 

Make recommendations to the 
Governing Board on 
Policies and 
Development 
Standards 
Budget and Fees 
Vendors 
Related Items 


FUNDING: 

Legislative appropriations to be provided via HESO or direct from legislature. 
Operational Costs for MILS (System X) to be provided by participants in System X 
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In order to protect the value of MnLINK, so there is more equal sharing of resources throughout the 

Network and no one library abuses its participation in MnLINK, each library will: 

1 . Develop a plan for the effective utilization of technology in library and information services 
including MnLINK; 

2. Implement and fund a formal policy providing for upgrade of local equipment and technological 
infrastructure on an on-going basis in order for MnLINK remain state of the art; 

3. Provide its fair share of resources needed to operate the network including annual 
membership fees, participation in MnLINK activities, and payments toward a central fund for 
the upgrade and/or replacement of MnLINK hardware and software; 

4. Designate staff person(s) to be the official contact(s) for MnLINK related activities. Provide 
these persons with the opportunity and resources to obtain training to gain and maintain the 
skills necessary for effective system use; 

5. Ensure that all staff are provided with the training necessary to use the network effectively; 

6. Provide adequate financial support to meet current and on-going collection and operational 
needs; 

7. Have its governing authority sign an agreement with MnLINK certifying it meets and will 
continue to meet the requirements for participation. 



best copy available 



In order to participate, each library will: 



1 . Share resources by following established protocols, policies, and procedures 
agreed to by all library participants in MnLINK ; 

2. Participate in MnLINK-approved delivery services to move needed materials among participating 
libraries effectively; 

3. Ensure that appropriate staff attendance occurs at training sessions relating to effective and efficient 
resource sharing among libraries; 

4. * Be a member of the MINITEX Library Information Network, a Minnesota Regional Public Library 
System, or a Multi-county/Multitype Library System; 

5. Participate in MnLINK equitable interlibrary loan load leveling protocols to ensure fair use of 
resources among participating libraries; 

6. Participate where appropriate in cooperative collection management processes and joint purchasing 
of electronic resources; 

far* 7. Update and maintain MnLINK information such as serials holdings and current cataloging; 

W 

8. Participate in reciprocal borrowing arrangements to which it has agreed. (At present, public libraries 
honor reciprocal borrowing by their patrons borrowing directly from other public libraries. Academic 
libraries honor reciprocal borrowing only among libraries not by patrons unless arrangements have 
been made in local geographical areas.) 

* Criteria for MINITEX Participation 
Criteria for Multitype Library Systems 
Criteria for Minnesota Regional Public Library Systems 
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In order to participate, each library will: 

1 . Catalog using the USMARC record format; 

2. Install and operate system software which is Z39.50 version 3 compliant; 

3. Install and operate system software to provide a Web/Z39.50 interface; 

4. Index bibliographic records according to MINITEX/LDS Indexing Standards and Guidelines 
for Bibliographic Records ; 

5. Follow the Ml NITEX/LDS Bar Code Standards and Guidelines’, 

6. Provide security authentication which meets MnUNK standards; 

7. Operate using other standards endorsed by MnLINK; 

8. Meet minimum computer and local area network infrastructure for each level of functionality 
as defined by MnLINK. 
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